Re: [alpine-devel] apk and libraries that optionally replace others
On Tue, May 15, 2018 at 11:08 PM, William Pitcock
> 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
> 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.
For what it's worth, I am open to adding provider_priority=1 to
libdrm. But it's not my package, so I prefer to hear from ncopa who
maintains it first. Otherwise, you will need to rebuild the package.
Received on Tue May 15 2018 - 23:13:02 GMT