This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Why versioned library names?
- From: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- To: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 11 Dec 2018 09:53:08 +0530
- Subject: Re: Why versioned library names?
- References: <875zwovw5u.fsf@oldenburg.str.redhat.com>
On 23/11/18 5:32 PM, Florian Weimer wrote:
Why does the default “make install” command install the library files
with versions in their names and relies on symbolic links to provide the
official names?
Is this so that a previous version of glibc can be restored by using
sln? If this is the only reason, is it worth keeping this feature?
That has been my understanding as well; I'm not old enough to
definitively claim that it is.
As for removing this feature, on the contrary I feel like it's not
sufficient and that we need to strengthen this to make recoveries from
botched updates more solid, similar to the kernel. Right now a botched
glibc update means that you have to go looking for your rescue disc to
recover. An ideal set up would be:
1. Versioned (e.g. ld-2.25-200.fc29.so) glibc libraries
2. glibc symlinks set using sln at every boot by the kernel based on a
configuration file. A glibc update then only updates that configuration
file and a subsequent reboot picks up the correct glibc. This solves
the race conditions that occur with updates of different library files.
3. A kernel boot option glibcver=2.25-200.fc29 to override the
configuration file.
Siddhesh
PS: I won't call the config file a systemwide tunable file, but you
could call it that if you want ;)