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
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
