From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3753 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Preparing to release 0.9.12 Date: Fri, 26 Jul 2013 01:34:20 -0400 Message-ID: <20130726053420.GU4284@brightrain.aerifal.cx> References: <20130724200221.GA4256@brightrain.aerifal.cx> <20130725104459.3c29fc34@vostro> <20130725161654.GH4284@brightrain.aerifal.cx> <20130725195955.25cbc101@vostro> <20130726003851.GA20873@newbook> <20130726081327.3d915b49@vostro> 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 1374816871 14559 80.91.229.3 (26 Jul 2013 05:34:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jul 2013 05:34:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3757-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 26 07:34:34 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 1V2afh-0001WM-RH for gllmg-musl@plane.gmane.org; Fri, 26 Jul 2013 07:34:33 +0200 Original-Received: (qmail 28304 invoked by uid 550); 26 Jul 2013 05:34:33 -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 28293 invoked from network); 26 Jul 2013 05:34:33 -0000 Content-Disposition: inline In-Reply-To: <20130726081327.3d915b49@vostro> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3753 Archived-At: On Fri, Jul 26, 2013 at 08:13:27AM +0300, Timo Teras wrote: > > > The so versioning will not help for C++ related things. The most > > > important use case I had in mind is that, package managers that use > > > soversions for automatic dependencies, can insert proper "require > > > version XXX or later of this .so". That is, if we built with musl > > > X, we can detect that from .so, and record it. And later ensure > > > that musl X-1 will not satisfy the newly built package's > > > dependencies. Especially important when we are introducing new > > > symbols. > > > > > > On Debian, there's the "symbols" system; this lists all symbols with > > the version they appeared in, and the tools look through the symbols > > and find the lowest version providing all the symbols. > > > > But as a standard rule, _added_ symbols _do_ _not_ call for a new > > SONAME, since they do not break the ABI. > > Correct. > > The usual way is: > soname = . > filename = . > > And then have symlink soname -> filename. This would allow side-by-side > installation of different library versions if needed. > > But the "symbols" system looks interesting too. If doing that, the > lib-version would be then. A good related read was (explains also the > soname/filename concept): > http://developer.ubuntu.com/packaging/html/libraries.html > > While SONAME we want to keep stable, and change only in the unlikely > event of abi breakage. I think it'd be still nice allow easily the > suffix to the generated file. One thing to keep in mind with libc is that you want to be able to safely and atomically replace it during an upgrade without any intermediate state where the system is unusable. This means the actual filename (as opposed to symlink) needs to be something that does not change between versions. If, for example, you had: /lib/ld-musl-$(ARCH).so.1 -> /lib/musl.so.1.0.0 and wanted to upgrade to musl 1.0.1, you would have to change the symlink to point to a different name. But there is (as far as I know) no way to replace a symlink atomically; you have to unlink it first then make a new symlink. And this leaves a race window during which exec() could fail. If the real file's name is something version-independent, however (either the current direction symlink or the reverse), then upgrading is simple: rename("libc.so.tmp12345", "libc.so"); or rename("/lib/ld-musl-i386.so.1.tmp12345", "/lib/ld-musl-i386.so.1"); It's atomic at runtime, and on a robust filesystem, there will not be a chance of ending up with an unusable system even if it crashes during the upgrade. I don't see any good way to bring version numbers into this. Rich