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