Re: Best way to handle sub-package conflicts
On Sun, 18 Mar 2018 12:44:37 -0400, Digimer wrote: > I think "Conflict" is the way to go. However, given how much the guide > urges not to use 'Conflicts', I worry that will make it > harder/impossible later to have the package accepted into Fedora. > > Would a use-case like this be an acceptable exception, would you guess? > > As I mentioned in my reply to Micheal, I am not worried about > auto-removal. If it simply refused to install one sub-package until the > other is gone, that's fine. There are runtime solutions, such as using "alternatives", which you may need to use to get such packages accepted into the Fedora package collection. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Best way to handle sub-package conflicts
Digimer wrote: > I think "Conflict" is the way to go. However, given how much the guide > urges not to use 'Conflicts', I worry that will make it > harder/impossible later to have the package accepted into Fedora. If your goal is to get the package into Fedora, will those hardcoded mutually exclusive roles even still make sense then? To me, this looks very much like policy specific to your deployment. Other deployments might want to allow a machine to take multiple of the roles you describe. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Best way to handle sub-package conflicts
On Sun, Mar 18, 2018 at 12:44:37PM -0400, Digimer wrote: > On 2018-03-18 11:48 AM, Nicolas Mailhot wrote: > > Le dimanche 18 mars 2018 à 11:22 -0400, Digimer a écrit : > >> > >> So this isn't a version conflict, as seems to be what Conflicts and > >> Obsoletes are designed to handle, if I understand properly. > > > > It is a conflict between the packages. > > > > What you can’t do is to allow the installation of one package to replace > > the others, because for rpm and dnf installations and updates have the > > same constrains (so if foo-b is allowed to replace foo-a it will do it > > for updates too) > > > > So you have too solutions: > > > > 1. make the packages conflict, to force users to choose one of them. > > Installation of each packages will be forbidden while one of the others > > is present > > > > 2. make sure the packages do not conflict, and can be parallel > > installed. Handle role conflicts at runtime, making sure whatever is > > executed in each role refuses to run if one of the others is already > > running (via lockfile for example) > > Hi, > > I think "Conflict" is the way to go. However, given how much the guide > urges not to use 'Conflicts', I worry that will make it > harder/impossible later to have the package accepted into Fedora. > > Would a use-case like this be an acceptable exception, would you guess? > > As I mentioned in my reply to Micheal, I am not worried about > auto-removal. If it simply refused to install one sub-package until the > other is gone, that's fine. Maybe another way to do it is to have a configuration file describing the "role" of the machine: /etc/anvil.conf: role = striker The services check this file at start up (or with a systemd precondition perhaps) and disable themselves if the role does not match, but they can still be parallel installed. Has the advantage that the sysadmin has to actively choose to change the role of a machine, rather than having some random package update change it accidentally. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Best way to handle sub-package conflicts
I should add, in a properly deployed rpm system, deploying (downloading/installing), configuring and running are three completely separate steps that do not imply one another. (deploying and updating OTOH are quite similar) It is a very powerful model that renders many complex operations easy to handle. However, it is also completely confusing to people that come from systems with less advanced facilities, that are used to compensate the management limitations with complex scripted or manual operation that mix all phases in random order. Learn to separate the steps in your design, you'll soon find out it makes a lot of things simpler and rpm/dnf can take care transparently of many things that used to be manual. Trying to impose a workflow that is contrary to rpm/dnf basic design usually ends badly. Not that rpm/dnf is not flexible enough to do it but it usually works a lot worse than using them as they are intended to be used (as all the people that try to replicate windows installers scripts rediscover every year). -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Best way to handle sub-package conflicts
On 2018-03-18 11:48 AM, Nicolas Mailhot wrote: > Le dimanche 18 mars 2018 à 11:22 -0400, Digimer a écrit : >> >> So this isn't a version conflict, as seems to be what Conflicts and >> Obsoletes are designed to handle, if I understand properly. > > It is a conflict between the packages. > > What you can’t do is to allow the installation of one package to replace > the others, because for rpm and dnf installations and updates have the > same constrains (so if foo-b is allowed to replace foo-a it will do it > for updates too) > > So you have too solutions: > > 1. make the packages conflict, to force users to choose one of them. > Installation of each packages will be forbidden while one of the others > is present > > 2. make sure the packages do not conflict, and can be parallel > installed. Handle role conflicts at runtime, making sure whatever is > executed in each role refuses to run if one of the others is already > running (via lockfile for example) Hi, I think "Conflict" is the way to go. However, given how much the guide urges not to use 'Conflicts', I worry that will make it harder/impossible later to have the package accepted into Fedora. Would a use-case like this be an acceptable exception, would you guess? As I mentioned in my reply to Micheal, I am not worried about auto-removal. If it simply refused to install one sub-package until the other is gone, that's fine. -- 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Best way to handle sub-package conflicts
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Best way to handle sub-package conflicts
Le dimanche 18 mars 2018 à 11:22 -0400, Digimer a écrit : > > So this isn't a version conflict, as seems to be what Conflicts and > Obsoletes are designed to handle, if I understand properly. It is a conflict between the packages. What you can’t do is to allow the installation of one package to replace the others, because for rpm and dnf installations and updates have the same constrains (so if foo-b is allowed to replace foo-a it will do it for updates too) So you have too solutions: 1. make the packages conflict, to force users to choose one of them. Installation of each packages will be forbidden while one of the others is present 2. make sure the packages do not conflict, and can be parallel installed. Handle role conflicts at runtime, making sure whatever is executed in each role refuses to run if one of the others is already running (via lockfile for example) Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Best way to handle sub-package conflicts
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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Best way to handle sub-package conflicts
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Best way to handle sub-package conflicts
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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Best way to handle sub-package conflicts
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. Thanks! -- 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
