From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2882 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl vs. Debian policy Date: Thu, 7 Mar 2013 08:04:24 -0500 Message-ID: <20130307130424.GW20323@brightrain.aerifal.cx> References: <20130306152913.59b2e776.idunham@lavabit.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1362661480 5703 80.91.229.3 (7 Mar 2013 13:04:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Mar 2013 13:04:40 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2883-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 07 14:05:04 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UDaVJ-0006iG-9S for gllmg-musl@plane.gmane.org; Thu, 07 Mar 2013 14:05:01 +0100 Original-Received: (qmail 21637 invoked by uid 550); 7 Mar 2013 13:04:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21627 invoked from network); 7 Mar 2013 13:04:38 -0000 Content-Disposition: inline In-Reply-To: <20130306152913.59b2e776.idunham@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2882 Archived-At: 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