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:
- 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. :)