Re: Preparing to release 0.9.12

[Rich Felker <dalias@aerifal.cx>]

On Fri, Jul 26, 2013 at 09:07:51AM +0300, Timo Teras wrote:
> On Fri, 26 Jul 2013 01:34:20 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > 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.
> 
> man rename(2) says:
>        If  oldpath  refers  to a symbolic link the link is renamed; if
>        newpath refers to a symbolic link the link will be overwritten.
> 
> But if this is linux specific, and we want to support other operating
> system kernels than linux, then this might be an issue.

Oh, I was being stupid. Of course this isn't Linux-specific. See
http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html

So if you want the unversioned name to be a symlink to the versioned
one, then what you do is:

symlink("/lib/musl.so.1.0.1", "/lib/tmp12345");
rename("/lib/tmp12345", "/lib/ld-musl-i386.so.1");

From a shell script, however, it seems you need to explicitly perform
these operations with ln and mv. The "ln -sf" command is specified to
operate via unlink, rather than renaming a temporary link, so it has
the race condition.

This gives us some more flexibility in how the installation and links
work.

Rich