Re: Best way to handle sub-package conflicts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux