Re: musl vs. Debian policy

[Isaac Dunham <idunham@lavabit.com>]

On Thu, 07 Mar 2013 16:30:30 -0600
Rob Landley <rob@landley.net> wrote:

> > Debian policy requires that any public libraries have a version  
> > number.
> 
> Looks like it's "1" here.
True, though shipping a "libc.so.1" might not be the ideal choice (mainly for publicity-related reasons).

> > 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.
> 
> Debian is incapable of renaming files when packaging them into .debs or  
> installing them, in order to enforce Debian's own policies?

It's quite possible; the issue is whether we'd end up "encouraging" them to package musl in a way that guarantees incompatability with everyone else.  If they install the x86_64 version as 
"/lib/ld-musl-amd64-el.so.1" 
(what dpkg-architecture might encourage if debian/rules installs libc.so itself), then musl on Debian amd64 would be incompatible with musl elsewhere.

> > 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.
> 
> Um, you said the dynamic linker name is a symlink to libc.so? So what  
> does "ship only the dynamic linker" mean in this context?
> 
mv libc.so ld-musl-$ARCH.so.1
ln -s ld-musl-$ARCH.so.1 libc.so # link goes in musl-dev

Does that clarify things?

-- 
Isaac Dunham <idunham@lavabit.com>