On 2018-03-18 11:12 AM, Michael Schwendt wrote: > On Sun, 18 Mar 2018 10:22:49 -0400, Digimer wrote: > >> Hi all, >> >> I am creating a new RPM package for a cluster project we've created. >> There is a common "core" package, and then three other packages that are >> installed depending on the machine's role in the cluster; >> >> foo-core >> foo-A >> foo-B >> foo-C >> >> If 'foo-A' is installed, I want 'foo-B' and 'foo-C' to be removed, and >> 'foo-B' replaces 'foo-A' and 'foo-C', etc. I originally planned to use >> 'Conflicts: ' in our spec, but reading this: >> >> https://fedoraproject.org/wiki/Packaging:Conflicts >> >> It seems like 'Conflicts' is strongly discouraged. So instead I tried >> 'Obsoletes', and this seemed to work in that, if 'foo-A' was installed >> and I tried to install 'foo-B', it would remove 'foo-A'. So I thought I >> was ok, until I bumped the version and tried to to an update. With >> 'foo-A' installed, it wanted to install 'foo-B' and 'foo-C' and failed, >> which makes sense now that I think of it. >> >> What is the best way to handle this in the .spec file? I'm having >> trouble finding the right term to search form. > > Could you proof-read your mail and correct the update scenario? > First you wanted foo-A to replace foo-B and foo-C. Next you write that > foo-B replaces foo-A and foo-C. Something's wrong in your description. > Under normal circumstances, a subpackage would never replace a > package with a different %name. > > Better split your packaging scenario in two clear parts: > 1) The packages that have been published before and which you start with. > Describe them and their inter-package dependencies. > 2) The set of packages you want to continue with after a major upgrade > that replaces/removes packages. Describe them and their inter-package > dependencies. > > Obsoletes tags usually are versioned, so they only remove older packages > up to a maximum version. That way you can reintroduce packages in the future. > If you keep building subpackages you've obsoleted before, they remain > available to be installed, and you would need to increase the version in > your Obsoletes tags to cover them. Nevertheless, subpackages with > different names would never replace eachother. Unless you've added > Obsoletes tags to do that. I'm sorry if I wasn't clear, perhaps I needed more coffee. Let me use specifics; Our cluster has hardware that play one of three roles; "Striker" (user dashboard and database host), "nodes" which hosts virtual servers that can live-migrate between nodes, and "dr" hosts which are used for disaster recovery in case the main cluster is destroyed. So the .spec creates four RPMs; "anvil-core", "anvil-striker", "anvil-node" and "anvil-dr". All machines require "anvil-core", plus one (and only one) of the other three packages. There is no scenario where, for example, 'anvil-node' and 'anvil-striker' would be installed on the same machine. So if a user has 'anvil-striker' RPM installed, and they try to install 'anvil-node', I want that to remove 'anvil-striker'. Similarly, if a machine has 'striker-node' already installed and the user tries to install 'anvil-dr', I want 'anvil-node' removed. This is because a single machine can only play one role at a time. So this isn't a version conflict, as seems to be what Conflicts and Obsoletes are designed to handle, if I understand properly. I hope I made more sense this time. :) -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
