[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130726053420.GU4284@brightrain.aerifal.cx>
Date: Fri, 26 Jul 2013 01:34:20 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Preparing to release 0.9.12
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 = <lib-name>.<abiver>
> filename = <soname>.<lib-version>
>
> 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
> <lib-version> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
