Re: musl vs. Debian policy

[Rich Felker <dalias@aerifal.cx>]

On Wed, Mar 06, 2013 at 03:29:13PM -0800, Isaac Dunham wrote:
> I started writing a short explanation of the musl installation for packagers, and realized that there's one area that's inconvenient:
> $syslib/ld-musl-*.so.1 is a symlink to libc.so.
> 
> Debian policy requires that any public libraries have a version number. 
> Specifically, Debian Policy 8.2 
> (http://www.debian.org/doc/debian-policy/ch-sharedlibs.html): 
> If your package contains files whose names do not change with each
> change in the library shared object version, you must not put them
> in the shared library package. Otherwise, several versions of the
> shared library cannot be installed at the same time without filename
> clashes, making upgrades and transitions unnecessarily difficult.

Are you sure this applies? I don't think the libc.so in musl counts as
a "public library" as nothing references it by name. Moreover, if
installing as a package on a glibc-based distro, it should not be
installed in /usr/lib (where it would clash with glibc's libc.so
linker script) but rather its own path.

> The apparent solution to this is to ship only the dynamic linker,
> since this is all we need (the dependency on libc.so is disregarded
> when it comes to running dynamically linked programs). But
> currently, actually doing this would be somewhat of a hack.
> 
> Is there any prospect of installing lib/libc.so straight to
> ${LDSO_PATHNAME} ? I'm thinking it could be done via something like:

This has been proposed before, and the main obstacle was build-system
difficulties if I remember right. I'd still like to consider doing it,
but it would be nice to be able to do it for its own sake rather than
for the sake of satisfying distro policy being applied where it
doesn't make sense. Maybe we can try to figure out Debian's stance
before we rush into making the change for their sake.

Rich