Dealing with packages which provide the same dependency

Removing a package y from world which provides=x (regardless whenever there are packages in the system which depend on x) via apk del y and then installing x via apk add x will replace y with x. It just seems logically correct.

As a workaround you can apk upgrade --available

actually for these specific cases (swapping from pipewire-pulse to pulseaudio after apk del pipewire-pulse, and the same for the -staging case) you don't need the -a, it swaps with just upgrade. i forget the reasoning why it doesn't apply instantly after del and the initial recalculation (reproduced it on alpine just now).

if i had to guess, upgrade does something more, since fix doesn't install the new one either, it's upgrade specifically that will recalculate in a way to fix it.

so that seems like more of a bug than some sort of feature request that apk add pulseaudio should transition from pipewire-pulse to pulseaudio after del on the former; if anything you shouldn't even need the add, it should happen straight away after del. there might be some actual reason that doesn't happen, but timo can answer that :)

in chimera, we use slightly different provides= packaging for this kind of case, where we have an explicit *-default package that holds the link from /usr/bin/thing to the specific impl (e.g. multiple /usr/bin/pinentry providers, like -curses, -qt, etc). there, the behaviour looks like:

# apk add gnupg # this pulls pinentry-curses-default
# apk add pinentry-qt-default
The following packages will be REMOVED:
  pinentry-curses pinentry-curses-default
The following NEW packages will be installed:
....

# apk del pinentry-qt-default
World updated, but the following packages are not removed due to:
  pinentry-qt-default: gnupg
# apk add pinentry-curses-default
The following packages will be REMOVED:
...
The following NEW packages will be installed:
  pinentry-curses pinentry-curses-default

...which has the exact behaviour you want :) del of the first thing and add of the second does what you describe. i'm not sure if this is somewhat different in apk3 (in which case alpine will work exactly how you want it to after moving to apk 3 and perhaps adopting this packaging), or if it's a difference in our packaging / the way the dependencies are laid out (in which case the fix for what you describe would be in the way alpine packages things and not in apk, sans that thing i mentioned above regarding add/upgrade/del).

if my hazy memory is right though, this is slightly different in apk3 and not something alpine can fix until they update. and then they should probably adopt the same thing chimera has for these multiple-providers-for-PATH-binary-thing that works as you want

or apk add '!wine-staging'. But I'm sorry but it's not obvious at all, especially use of exclamation mark.

there could probably be more documentation on how this control over the dependency graph works (i'm not sure if ! is even documented in the manpages at all currently.. uhh...), but there is nothing wrong with this exclude syntax, nor is it weird that that the world file has a way to have an 'exclude' constraint on top of the default 'include' constraint (since that's all the world file is, a list of includes/excludes, etc). ! seems like a better character to use for that than anything else that is available (it's limited within reason to the ascii set, and all the other fancy characters are already reserved i think for the version part, etc). maybe ^ is available(? it's 4am and i didn't check) but at this point it's too late to change it i think...

(i do admit it's not obvious that this is one way to resolve wanting to swap from one package to the other given it should work better as mentioned way above, but the rest of this is fine)

This also affects apk fetch functionality. In a system with wine-staging, apk fetch wine downloads wine-staging

this, as a completely separate case (i.e. this seems like a whole second separate issue), would probably be better if it preferred the exact name first (i.e. for apk fetch foo where a concrete foo doesn't exist, but things provides= foo, it would pick the highest priority, but when there is an actual pkgname=foo, that one would always come first instead of looking at priority/provider versions/whatever).

it's also a bit more funny than you describe- it's not even in "a system with wine-staging", it happens even while having wine installed, with wine in world, just with the testing/ repos enabled (where wine-staging provides= a lower wine=1 than wine itself); it still downloads wine-staging.apk despite all that. this looks like a bug:

/ # apk info -P wine
wine-9.9-r0 provides:
cmd:msidb=9.9-r0
cmd:wine-preloader=9.9-r0
cmd:wine64-preloader=9.9-r0
cmd:wine64=9.9-r0
cmd:wine=9.9-r0
cmd:wineapploader=9.9-r0
cmd:wineserver=9.9-r0

wine-staging-9.14-r0 provides:
wine=1-r0
cmd:msidb=9.14-r0
cmd:wine-preloader=9.14-r0
cmd:wine64-preloader=9.14-r0
cmd:wine64=9.14-r0
cmd:wine=9.14-r0
cmd:wineapploader=9.14-r0
cmd:wineserver=9.14-r0

/ # apk list -I wine
wine-9.9-r0 x86_64 {wine} (LGPL-2.0-or-later) [installed]

/ # apk fetch wine
Downloading wine-staging-9.14-r0

i assume it's only taking the top-most version from the package that actually provides= the thing, and not the version of what it is providing, so 9.14 'wins'.

Instances where this has already happened:

all of these are unrelated to what you describe in the actual issue (swapping between a provider for a certain name on a system and having difficulty with it); in these issues, one was an actual apk bug (that one is fixed), and in the other, it seems it was more a packaging / constraints issue than an actual bug somewhere (i.e. if in some case you never want pipewire-pulse, obviously you should ! it, but that was not done until that fix mr). if there is an actual bug in the second case that made pipewire-pulse pulled despite it having a lower priority and nothing explicitly adding it, maybe that should be reported too (seems nobody tracked it down at all), but it's unrelated to what you've described in this issue as a whole.

The behavior brought a lot of confusion to me so it wasn't apparent whenever this is a bug, an oversight or just the intended behavior.

i'm not sure if this is somewhat different in apk3 (in which case alpine will work exactly how you want it to after moving to apk 3 and perhaps adopting this packaging), or if it's a difference in our packaging / the way the dependencies are laid out (in which case the fix for what you describe would be in the way alpine packages things and not in apk, sans that thing i mentioned above regarding add/upgrade/del).

I'm all for it being implemented directly in apk. Packaging with *-default is a solution still, but I'd like to see handling for this specific case without changes to packaging.

there could probably be more documentation on how this control over the dependency graph works (i'm not sure if ! is even documented in the manpages at all currently.. uhh...)

I knew about ! syntax in APKBUILD, but I didn't know it could be used directly in apk add

but there is nothing wrong with this exclude syntax

There is at least one annoyance. In zsh, !string is evaluated as <most recent command which starts with string (I think?)>, so unless you quote it, it will do that. Other package managers don't have such syntax so I never had to think about it.

So wine-staging does not provide wine with version higher than the "normal" wine. And apk del wine-staging && apk upgrade should have done the thing. apk del basically does minimal changes to system only and its not possibly to specify it to upgrade mentioned packages if possible. The oneliner would have been apk add wine !wine-staging as mentioned, but is agreeable non-obvious.

The current behavior actually is wanted in cases where there is package and package-ng where the -ng variant is the new introduced in the next major release. It would need to provide package with higher version so that automatic upgrade works, and package should not be "downgraded" to in similar cases.

What comes to apk fetch wine downloading wrong package, it has been fixed in commit ec2ca333 and is included in 2.14.1 release.

The problem with pulseaudio and pipewire-pulse is another one. I think it is a packaging mistake that pipewire-pulse provides pulseaudio with pipewire's own version number. It also sets provider_priority to allow automatic installation (perhaps to select it automatically if we have a partial repository clone without pulseaudio?). Fortunately pipewire version is lower than pulseadio, so pulseaudio is normally favored. But again, in this case apk del would not change things because it tries to make minimal changes.

I think as a simple fix apk del could be adjusted to not prefer the installed packages that are named. That should trigger re-evaluation of the providing package and allow package switch in this case. It should fix both cases. Assuming packager have not done provides dependencies that would tip the preference to another package.

cc @ncopa @ariadne

What comes to apk fetch wine downloading wrong package, it has been fixed in commit ec2ca333 and is included in 2.14.1 release.

that repro reproduces on 2.14.4 currently. i see the commit is really in 2.14-stable and in the releases, but perhaps doesn't work for some reason?

mentioned in commit 853873e5

mentioned in commit 9e7c3518

mentioned in commit 6246d947

closed with commit 30f89ce0

mentioned in commit cdae4fe4

mentioned in commit 8f223f61

I think this caused us downstream a issue, where doas-sudo-shim and sudo provide sudo-virt, but apk chooses sudo and isn't satisfied with doas-sudo-shim. But i'm currently not able to reproduce it by manually, only in pmbootstrap..

ERROR: unable to select packages:
  sudo-1.9.16_p1-r1:
    conflicts: doas-sudo-shim-0.1.1-r1[cmd:sudo=1.9.16_p1-r1]
    breaks: doas-sudo-shim-0.1.1-r1[!sudo]
    satisfies: postmarketos-base-38-r0[sudo-virt]
               postmarketos-base-nofde-38-r0[sudo-virt]
  doas-sudo-shim-0.1.1-r1:
    conflicts: sudo-1.9.16_p1-r1[cmd:sudo=0.1.1-r1]
    satisfies: postmarketos-base-doas-38-r0[doas-sudo-shim]
               postmarketos-base-38-r0[sudo-virt]
               postmarketos-base-nofde-38-r0[sudo-virt]

FWIW here is the APKBUILD for postmarketos-base: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/master/main/postmarketos-base/APKBUILD, it should install sudo-virt doas doas-sudo-shim and not sudo at all.

I'm fairly sure this is unrelated issue. Please open new one issue for this.

What likely happens is that the order of locking packages changed, and made apk select sudo before it even saw the dependency to doas-sudo-shim. This requires non-trivial solver code because in this particular case both provide cmd:sudo and the right choice of doas-sudo-shim provides cmd:sudo which a version smaller (less preferred) than sudo.

More probably commit that might have this as side effect is 8a72686d. But even here the result is due to ordering, and could have been triggered in other scenarios depending on what is in the indexes. So fixing this issue properly is simply not reverting that, but adjusting the logic to take this into account (assuming there is no dependency loops or other packaging issues in the indexes).

mentioned in issue #11045 (closed)

Dealing with packages which provide the same dependency

For example

Instances where this has already happened:

My proposed solution

Designs

Child items ...

Activity