Re: musl vs. Debian policy

[Rich Felker <dalias@aerifal.cx>]

On Thu, Mar 07, 2013 at 08:03:54PM -0800, Isaac Dunham wrote:
> 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

This is mostly correct. I agree that for this usage the symlink should
go in the opposite direction. Perhaps that's a good enough argument
that the build system should install it to go in the opposite
direction.

However note that if "musl-1" and "musl-2" were really incompatible
enough to need a different version number, sets of libraries linked
against them would probably be likewise different, and it would
probably not work to use the same lib directory for both... That's the
whole reason we _don't_ want to be changing things.

Rich