Re: musl vs. Debian policy

[Isaac Dunham <idunham@lavabit.com>]

On Thu, 7 Mar 2013 20:10:10 -0500
Rich Felker <dalias@aerifal.cx> wrote:

> 
> The problem is that you don't understand that the reasons DON'T APPLY
> to musl. libc.so is purely a filename for the "ld" command to find. It
> has nothing to do with runtime or versioning. The only musl library
> file that will be searched when loading applications is
> /lib/ld-musl-$(ARCH).so.1, which DOES have a version number. The
> version number is encoded in the PT_INTERP rather than a DT_NEEDED
> header.

I understand that /lib/ld-musl-$(ARCH).so.1 is the only filename that a dynamically-linked binary sees. 
However, if ld-musl-$(ARCH).so.1 is a symlink to libc.so, then anyone preparing a binary package must include libc.so in that package. 
Incrementing the soversion (.so.1 -> .so.2) would not allow parallel installs. To illustrate, here's the layout I'm expecting with multiarch based on the current build system.
musl1:
/usr/lib/i486-linux-musl/libc.so
/lib/ld-musl-i386.so.1 => /usr/lib/i486-linux-musl/libc.so

musl2 (if ABI breaks):
/usr/lib/i486-linux-musl/libc.so
/lib/ld-musl-i386.so.2 => /usr/lib/i486-linux-musl/libc.so

I don't see any way for musl2 to be co-installed in a functional way, unless you change the triplet to i486-linux-musl2. Otherwise, you get the new ABI for both symlinks, breaking old binaries.
A more conventional layout, with all libraries in /usr/lib or /lib, would
have the same problem, but would not have the option of just changing the triplet/libdir.
Even if you are not using a binary-package-based distro, a library with the incremented soversion would still break old libraries, since ld-musl-$(ARCH).so.1 points to the new libc.so.

Is this analysis missing something?

Thank you,
Isaac Dunham <idunham@lavabit.com>