repository-tag pinning is sometimes ignored
I found a weird edge case where the solver will ignore a repository tag pinning. Naturally, this came up while trying to illustrate why making a "frankenstein" environment combining Alpine and Wolfi components is generally disallowed.
For context, Wolfi's glibc package has an explicit conflict declared against musl. This is intended to prevent users from combining Alpine and Wolfi packages since obviously that will create stability problems.
Both Wolfi and Alpine have packages which satisfy the librdkafka
name. So, if we start from a Wolfi environment:
8d94d6bb5b51:/# apk add alpine-keys
(1/1) Installing alpine-keys (2.4-r2)
OK: 17 MiB in 19 packages
And we trust the Alpine x86_64 signing keys:
8d94d6bb5b51:/# cp /usr/share/apk/keys/x86_64/alpine-devel@lists.alpinelinux.org-* /etc/apk/keys/
And we add @alpine https://dl-cdn.alpinelinux.org/alpine/edge/community
to /etc/apk/repositories
, then installing packages which are only in Alpine fails as we would expect:
8d94d6bb5b51:/# apk add stargazer-gmi@alpine
ERROR: unable to select packages:
so:libc.musl-x86_64.so.1 (no such package):
required by: stargazer-gmi-1.0.5-r2[so:libc.musl-x86_64.so.1]
But as previously mentioned, librdkafka
is in both distributions, so what happens when we install librdkafka@alpine
?
8d94d6bb5b51:/# apk add librdkafka@alpine
(1/5) Installing libgcc (13.2.0-r3)
(2/5) Installing liblz4-1 (1.9.4-r3)
(3/5) Installing libstdc++ (13.2.0-r3)
(4/5) Installing libzstd1 (1.5.5-r1)
(5/5) Installing librdkafka (2.3.0-r0)
OK: 23 MiB in 24 packages
This is the wrong librdkafka
as should be obvious since the installing line does not describe the installed package as librdkafka@alpine
. We can verify this by checking the shared libraries it depends on:
8d94d6bb5b51:/# /lib/ld-linux-x86-64.so.2 --list /usr/lib/librdkafka.so.1
(0x00007fc54e54d000)
linux-vdso.so.1 (0x00007fff17dd0000)
libm.so.6 => /lib/libm.so.6 (0x00007fc54e46d000)
libz.so.1 => /lib/libz.so.1 (0x00007fc54e453000)
libzstd.so.1 => /usr/lib/libzstd.so.1 (0x00007fc54e394000)
libssl.so.3 => /usr/lib/libssl.so.3 (0x00007fc54e2ef000)
libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x00007fc54de30000)
liblz4.so.1 => /usr/lib/liblz4.so.1 (0x00007fc54de09000)
libc.so.6 => /lib/libc.so.6 (0x00007fc54dbd2000)
/lib/ld-linux-x86-64.so.2 (0x00007fc54e759000)
I would expect the solver to reject this solution since it does not keep the @alpine
tag, like it rejects installing stargazer-gmi@alpine
.