From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2890 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl vs. Debian policy Date: Thu, 7 Mar 2013 16:22:06 -0800 Message-ID: <20130307162206.f5cc2136.idunham@lavabit.com> References: <20130306152913.59b2e776.idunham@lavabit.com> <1362695430.6812.8@driftwood> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1362702141 18406 80.91.229.3 (8 Mar 2013 00:22:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Mar 2013 00:22:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2891-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 08 01:22:44 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 1UDl59-0000QT-9M for gllmg-musl@plane.gmane.org; Fri, 08 Mar 2013 01:22:43 +0100 Original-Received: (qmail 6100 invoked by uid 550); 8 Mar 2013 00:22:21 -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 6085 invoked from network); 8 Mar 2013 00:22:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=TMIa5D6Fj+UZCQx411lf368hU/LoPOUsSI7wYhYtvj+OGGVnVPPaLdPTII7SOOTDl1r7xayZeOQ9/PNEW4NCaLjq7m9J9pjyUVmVvaZ416RYDmvtOClZUErum673gRnxoFdhEvP6OZGg+oKJlDPN9MGkkH+bgB1axgEIhuOv2Oo=; h=Date:From:To:Subject:Message-Id:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; In-Reply-To: <1362695430.6812.8@driftwood> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; i486-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:2890 Archived-At: On Thu, 07 Mar 2013 16:30:30 -0600 Rob Landley 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