Mail archive
alpine-devel

Re: [alpine-devel] apk and libraries that optionally replace others

From: William Pitcock <nenolod_at_dereferenced.org>
Date: Tue, 15 May 2018 23:08:45 -0500

Hello,

On Tue, May 15, 2018 at 3:57 PM, Oliver Smith
<ollieparanoid_at_bitmessage.ch> wrote:
> Hey folks,
>
> in Alpine based postmarketOS we have hit the following use case quite a
> few times by now, and we're wondering how to solve it properly:
> Packaging "testlib-b" as a _optional_ replacement for "testlib-a".
>
> Both "testlib-a" and "testlib-b" provide the same soname, which means
> abuild will automatically make both binary packages provide
> "so:libtestlib.so.1".

By default this means that both packages will provide
so:libtestlib.so.1 with provider_priority 0. When provider_priority
is 0, it means to skip automatically resolving the provider. Provider
selection is based on a combination of priority and overall "cost" of
choosing that provider. apk will prefer the highest priority provider
with the lowest cost (dependency chain length) that can yield a
satiable solution.

> Now there is a "testapp" package, which has "testlib-a" in makedepends
> and links against "libtestlib.so.1". Therefore abuild puts
> "so:libtestlib.so.1" in the depends of "testapp". What we would like to
> achieve is, that whenever installing "testapp", it pulls in "testlib-a".
> But when "testlib-b" is already installed, it uses "testlib-b" instead
> of "testlib-a".

testlib-b (libdrm) should have provider_priority 1, testlib-a
(libdrm-grate) should have provider_priority greater than 1. The
provides field itself should be left alone. The key is to set a
priority on both providers, otherwise APK will treat it as a collision
and behave as you describe.

> I have tried various combinations with "provides" and
> "provider_priority", and I couldn't get it working. The only way it
> would work was if "testapp" explicitly depended on "testlib-a", but that
> won't fulfill our use case: if the library in question is "libdrm", then
> we would need to change a lot of Alpine's aports to explicitly depend on
> libdrm instead of implicitly to make it work.
>
> If someone is interested, I can provide apk's output of what I've tried
> so far. The aports I have used for testing are here [1].
>
> To make this less abstract, one example where we would actually use
> this, is "libdrm-grate", which adds out of tree tegra drivers to
> "libdrm" [2].
>
> Here are my questions:
> * Am I missing something, or does this not work with apk?
> * Would Alpine be interested in a patch that adds this functionality,
> and if so, how would everyone like to have it integrated?
>
> Thanks for reading,
> Oliver
>
> [1]: https://github.com/ollieparanoid/apk-conflicts-example
> [2]:
> https://github.com/postmarketOS/pmbootstrap/issues/1380#issuecomment-385183609

William


---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Tue May 15 2018 - 23:08:45 UTC