musl - musl vs. Debian policy

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20130306152913.59b2e776.idunham@lavabit.com>
Date: Wed, 6 Mar 2013 15:29:13 -0800
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: musl vs. Debian policy

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.

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:

install-ldso: $(DESTDIR)$(LDSO_PATHNAME)

$(DESTDIR)$(LDSO_PATHNAME): lib/libc.so
        install -D -m 755 $< $@

I realize it would also be necessary to adjust the rules for installing libc.so, however. If the change is welcome, I could prepare a patch.

Thanks, 
Isaac Dunham <idunham@...abit.com>

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.