From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2881 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: musl vs. Debian policy Date: Wed, 6 Mar 2013 15:29:13 -0800 Message-ID: <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 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1362612570 18459 80.91.229.3 (6 Mar 2013 23:29:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Mar 2013 23:29:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2882-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 07 00:29:52 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 1UDNmQ-000279-II for gllmg-musl@plane.gmane.org; Thu, 07 Mar 2013 00:29:50 +0100 Original-Received: (qmail 25638 invoked by uid 550); 6 Mar 2013 23:29:28 -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 25630 invoked from network); 6 Mar 2013 23:29:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=L6jmnpZ/SbxtNeYPMVZVX/8RZOx/Cz8il38bjLX48Ty+fim/+2CcP6IE46niLMSJ1N396NWrz3/SetVI/oIHAbftTSNg9c6x1QbyBLSCU/bKVJZ3/+YZcDLK4y+dUzHQKp8/am1puUXuJvdzjZ9up1f6YLaHz1d8teeISlxsndQ=; h=Date:From:To:Subject:Message-Id:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; i486-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:2881 Archived-At: 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