Hello.
Assume I have two "stacks" of RPM packages available:
postgresql16 provides postgresql-any version 16 conflicts with other postgresql-any postgresql16-plugin provides postgresql-any-plugin requires postgresql16 conflicts with other postgresql-any-plugin
postgresql20 provides postgresql-any version 20 conflicts with other postgresql-any postgresql20-plugin provides postgresql-any-plugin requires postgresql20 conflicts with other postgresql-any-plugin
On my system, I have postgresql16 and postgresql16-plugin installed and I want to "upgrade" to postgresql20*.
Using my distribution package manager, I would want to run something like: dnf swap postgresql16 postgresql20
However that will fail, as the package manager does not know I want to also swap postgresql16-plugin with postgresql20-plugin.
Is there something I can do as a package maintainer to "guide" the co-dependent swap case?
I was thinking something like:
postgresql20-plugin: Obsoletes: (postgresql-any-plugin if postgresql-any != 20)
However that is not possible in RPM, "No rich dependencies allowed for this type: Obsoletes".
Is there anything else?
Thanks,
V Wed, Feb 21, 2024 at 10:54:16AM +0100, Miro Hrončok napsal(a):
Assume I have two "stacks" of RPM packages available:
postgresql16 provides postgresql-any version 16 conflicts with other postgresql-any postgresql16-plugin provides postgresql-any-plugin requires postgresql16 conflicts with other postgresql-any-plugin
postgresql20 provides postgresql-any version 20 conflicts with other postgresql-any postgresql20-plugin provides postgresql-any-plugin requires postgresql20 conflicts with other postgresql-any-plugin
On my system, I have postgresql16 and postgresql16-plugin installed and I want to "upgrade" to postgresql20*.
Using my distribution package manager, I would want to run something like: dnf swap postgresql16 postgresql20
However that will fail, as the package manager does not know I want to also swap postgresql16-plugin with postgresql20-plugin.
Is there something I can do as a package maintainer to "guide" the co-dependent swap case?
I don't think there is anything like "dnf module switch-to".
What works now is manually listing the new packages:
dnf install --allowerasing postgresql20 postgresql20-plugin
For the guided multi-swap, DNF would have to uderstand that postgresql20-plugin and postgresql16-plugin are different streams of the same software. If it doesn't understand it, --allowerasing will resolve to uinstalling the old packages without installing the new ones. (Because a dependency solver prefers smaller transactions (uninstalling N packages) over larger ones (uninstall N + install N).)
There is the postgresql-any-plugin Provide, but DNF does not know that it actually identifies what the user wants to retain. Hypothetically pinpointing it:
dnf upgrade --allowerasing postgresql-any postgresql-any-plugin
could do it. But I worry that DNF prefers interpreting the arguments as package names instead of as provides. (Especially in the real life where Fedora 41 now contains postgresql15 package providing postgresql next to postgresql package.)
Nonetheless, your guided swap with referring to a single provide/package:
dnf upgrade --allowerasing postgresql-any
would not work for the very same reason: DNF does not know that postgresql-any-plugin provide should be preserved, while any other provides of postgresql16-plugin package (e.g. postgresql16-plugin provide itself) do not matter.
To do that there would have to be two kinds of provides (i.e. a new RPM tag or a namespace in Provides) and DNF would have to handle the special postgresql-any and postgresql-any-plugin provides as "explicitly installed". Of course that would break current behavior. So this feature would have to be activated with a new option, e.g. --allow-swap, which would break the prohibition of uninstalling packages and enforced preserving the special provides:
dnf upgrade --allow-swap postgresql-any
So yeah, DNF does not have enough metadata. We need RPM-formalized alternatives.
-- Petr
* Miro Hrončok:
On my system, I have postgresql16 and postgresql16-plugin installed and I want to "upgrade" to postgresql20*.
Using my distribution package manager, I would want to run something like: dnf swap postgresql16 postgresql20
However that will fail, as the package manager does not know I want to also swap postgresql16-plugin with postgresql20-plugin.
Is there something I can do as a package maintainer to "guide" the co-dependent swap case?
Have you tried using “dnf shell” and entering both swap commands there/
Thanks, Florian
On 08. 03. 24 11:43, Florian Weimer wrote:
- Miro Hrončok:
On my system, I have postgresql16 and postgresql16-plugin installed and I want to "upgrade" to postgresql20*.
Using my distribution package manager, I would want to run something like: dnf swap postgresql16 postgresql20
However that will fail, as the package manager does not know I want to also swap postgresql16-plugin with postgresql20-plugin.
Is there something I can do as a package maintainer to "guide" the co-dependent swap case?
Have you tried using “dnf shell” and entering both swap commands there/
I am actually looking for a metadata solution that would guide the package manager to do it for me, not for a way to swap them manually.
On Fri, Mar 8, 2024 at 5:51 AM Miro Hrončok mhroncok@redhat.com wrote:
On 08. 03. 24 11:43, Florian Weimer wrote:
- Miro Hrončok:
On my system, I have postgresql16 and postgresql16-plugin installed and I want to "upgrade" to postgresql20*.
Using my distribution package manager, I would want to run something like: dnf swap postgresql16 postgresql20
However that will fail, as the package manager does not know I want to also swap postgresql16-plugin with postgresql20-plugin.
Is there something I can do as a package maintainer to "guide" the co-dependent swap case?
Have you tried using “dnf shell” and entering both swap commands there/
I am actually looking for a metadata solution that would guide the package manager to do it for me, not for a way to swap them manually.
There isn't one right now. It's something that could be added, but we don't have any in DNF currently. It might also require plumbing in libsolv, I'm not sure.
-- 真実はいつも一つ!/ Always, there's only one truth!
packaging@lists.fedoraproject.org