Fully replace libc6-compat and musl-utils

[LukeShu]

When upgrading 2.34→2.35, #171 also made the change that it drops the /lib64/ld-linux-x86-64.so.2 symlink and instead depend on libc6-compat's version of that symlink.

This broke us, as /lib/ld-linux-x86-64.so.2 was going for glibc, while /lib64/ld-linux-x86-64.so.2 was going for musl, and that managed to confuse our binary.

---

Dropping the symlink was justified by ERROR: glibc*: Packages must not put anything under /lib64, use /lib instead; but man apkbuild tells us about the lib64 value for options=:

Specifies that the package installs files under /lib64 or /usr/lib64 and that the test for those directories should be skipped. This is discouraged and should only be used for packages providing compatibility for GNU libc.

That's exactly the case for us! So say options="lib64" and add the symlink back. Since this means that we file-conflict with libc6-compat, explicitly declare that and say conflicts="libc6-compat".

---

What does libc6-compat do, what are the consequences of not being able to install both it and glibc at the same time? It adds glibc binary compatibility to musl, allowing binaries linked against glibc to use Alpine's native musl. So it doesn't really make sense to have both glibc and libc6-compat to be installed at once; if you have glibc installed that's a strong indicator that you want glibc-linked binaries to use the actual glibc and not musl. So the above conflicts= is probably the right thing. At the same time, the intent of libc6-compat can be written as "I'd like to be able to run binaries that are linked against glibc", so also say provides="libc6-compat".

The commit that added glibc-bin's dependency on libc6-compat (3987862) said "This package not being installed is a very common cause of reported user errors." I'm not sure what those reported user errors are; that claim doesn't make much sense to me.

---

I also added a glibc-utils counterpart to musl-utils; it just symlinks programs from glibc-bin's /usr/glibc-compat in to /usr.

---

I also gave glibc-bin a dependency on perl, as mtrace uses perl in its shebang.

---

I have not actually built or tested this.

[sgerrand]

Apologies for the incredibly delayed review.

[sgerrand]

This declaration isn't accurate but the line below it is.

Suggested change

provides="libc6-compat"

[LukeShu]

I'm not sure I understand why you think this is incorrect.

In the PR description I wrote:

the intent of libc6-compat can be written as "I'd like to be able to run binaries that are linked against glibc", so also say provides="libc6-compat".

Or, put another way: What could be more libc6-compatible than actually installing libc6?

[jalberti]

What could be more libc6-compatible than actually installing libc6?

provides is not meant to declare a capability, but should refer to packages provided, see also https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#provides. Further one could argue, the packages from this repository do not provide compatibility, they do provide glibc.

libc6-compat is a package, https://pkgs.alpinelinux.org/packages?name=libc6-compat&branch=v3.16&repo=&arch=&maintainer=.

[b01]

@jalberti I think I see why setting provide=libc6-compat is not what we would want; after the suggested reading by @sgerrand :

provides

List of package names (and optionally version info) this package provides.
If package with a version is provided (provides='foo=1.2') apk will consider it as an alternate name and it will automatically consider the package for installation by the alternate name, and conflict with other packages having the same name, or provides.

If version is not provided (provides='foo'), apk will consider it as virtual package name. Several package with same non-versioned provides can be installed simultaneously. However, none of them will be installed by default when requested by the virtual name - instead, error message is given and user is asked to choose which package providing the virtual name should be installed.

This definition shows that provides it meant as an alternate name for installation. Since this is glibc and not just a compatibility, it would make more since to set provide='glibc=2.35'

I'm not familiar with ABUILD, but there must be another way to show conflict between libc6-compat and other packages.

[b01]

@jalberti My this would work!?

depends="$pkgname bash !libc6-compat libgcc"

Notice the "!" added before libc6-compat. This makes the most since, and explains why that is in the depends list in the first place.

Excerpt from https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#depends

depends

Run-time dependency package(s) that are not shared-object dependencies. Shared objects dependencies are auto-
detected and should not be specified here. To specify a conflicting package, add the package name prefixed with a '!'.

[b01]

so then add
depends="$depends !libc6-compat" # conflicts with this package

[b01]

@LukeShu I believe that this PR is still VERY relevant and should be merged. But with the change I suggested:

depends="$depends !libc6-compat" # conflicts with this package

Would you be willing to rebase this PR with the latest and push an update?

[gjrtimmer]

I tried to build and install this PR, however, I ran into the following issue:

/pkgs/builder/x86_64 # apk add --allow-untrusted glibc-2.37-r0.apk
(1/1) Installing glibc (2.37-r0)
ERROR: glibc-2.37-r0: trying to overwrite etc/nsswitch.conf owned by alpine-baselayout-data-3.6.5-r0.
1 error; 13 MiB in 15 packages

@LukeShu any thoughts on this?