On 2018-03-18 11:40 AM, Michael Schwendt wrote: > On Sun, 18 Mar 2018 11:22:23 -0400, Digimer wrote: > >> 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. > > The description of the packaging scenario is not complete yet. > If -striker, -node and -dr are mutually exclusive, why is that? > Are there implicit conflicts in the packaged files? Then you cannot > avoid Conflicts tags. Or are there runtime conflicts? Then you should > look into a solution that would resolve the conflict with a configuration > file, which would define the operation mode of the software. > > So far, the scenario sounds very much as if you want to add Conflicts tags > to the subpackages as to achieve that only one of them can be > installed. Trying to simulate automatic removal of conflicts through > Obsoletes tags is not the right thing to do in your scenario. You would > end up with circular Obsoletes, which would confuse depsolvers or lead > to random behavior. The conflict is in the role the machine plays in the larger cluster, rather than an application-level conflict. So, for example, if the machine is "striker", it hosts the database and is not allowed to host servers. If a machine is a "node", it is allowed to be a live migration target, but must have synchronous storage replication. If a machine is "dr", it is allowed to host VMs, but it is not allowed to be a live migration target. These restrictions come from the design of the system, not from code-level incompatibility. I'm agreeing that "Conflicts" sounds like the right option, but my concern came from the guide's strong language against its use. I'm OK with the package not automatically removing the others, so long as the sub packages can't be installed at the same time. It is ok to just error and tell the user to remove the conflict first, then try again. -- 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
