libc soname conventions [was: libc6_2.0.106-0.1_i386.deb is released]
Hi!
>>>>> Santiago Vila writes:
>> The current soname is libc.so.0.2 which suggest that you should
>> use something like libc0_2.
I'm now using libc0.2 as the package name, which I agree is correct.
SV> Does this mean that some day there will be some move like the
SV> libc5 -> libc6 in Linux and that we will have to recompile
SV> everything?
Yes, as others have said.
I believe that after we have a reasonably stable `libc.so.0.x' series
with libio and pthreads functionality, we should change the soname to
`libc.so.6', and use that opportunity to make any final incompatible
changes we need in order to bring the Hurd's ABI in line with Linux's.
Then, we will be able to run many Linux binaries natively (without any
special emulation techniques).
Here are my thoughts:
There are currently two ``flavours'' of Debian GNU/Linux library
packages: `libSONAME' and `libSONAMEg'. Shared library packages whose
names end in `g' are now linked against libc6, but used to have a
non-g version that was linked against libc5.
Library packages that have never been linked against libc5 don't get
the `g' suffix. This convention made it possible to upgrade a Debian
system from libc5 to libc6 without breaking anything, because you
could have both versions of a given shared library package installed
at the same time (unlike certain chapeau-rouge-based systems I could
mention).
If we change the Hurd's glibc soname, then we should probably do a
similar renaming of shared library packages.
The only other guiding rule is that if a package doesn't work on both
i386 and hurd-i386, it should have different names for each of these
architectures. If a package works on both the Hurd and Linux, then it
should have a single canonical name: the one it already has under
Linux. That way, with maybe a few changes to dpkg, we can have a
forest of symlinks from the hurd-i386 distribution tree to i386.
If Linux and the Hurd ever find some way of cohabitating on the same
running system (i.e. this pie-in-the-sky GNUnification where Linux
eventually becomes a microkernel that hosts the Hurd), and we have
reason to do so, we can drop the hurd-i386 tree, and integrate the
Hurd as just another Debian GNU/i386 package. There, again, it makes
sense to have the same Debian package names so that former hurd-i386
users don't have to go through pains when ``upgrading'' back to the
standard i386 distribution.
So, my proposal is to do the following:
1) For shared library packages that we create that aren't
binary-compatible with Linux, we should avoid using the same name
as the Linux version of those packages. I would suggest the
following convention:
`libSONAMEpi' for libraries linked against libc.so.0.2.
`libSONAMEp' for libraries linked against a non-pthreads glibc.
`libSONAMEi' for libraries linked against a non-libio glibc.
`libSONAMEh' for libraries that have Hurd-specific features (and
need to be separately maintained from their Linux counterparts).
If there are any further ABI differences (besides just libio and
pthreads), then I suggest we document them, and associate them with
their own flag letters, or else schedule them to change at the same
time as libio or pthreads support gets added.
2) As soon as we get ``good enough'' ABI compatibility with Linux
(i.e. only kernel-dependent packages like `modutils' don't work),
we should change the Hurd's glibc soname to libc.so.6. At this
point, we can drop a huge number of hurd-i386 packages because
they'll be identical to the i386 ones... they'll just be using a
different underlying libc implementation and ``kernel''.
3) For the hurd-i386 shared library packages that we don't drop in
this transition (i.e. the ones with Hurd-specific features), we
will keep the `h' suffix, to distinguish them from their Linux
counterparts.
4) After this point, the Hurd has the technical potential to become a
standard part of Debian GNU/i386 (GNUnification). Then, we can use
symbol versioning to make any future changes to the libc ABI, so
we'll be stuck at libc.so.6 for eternity (or reasonable facsimile
thereof).
So, if somebody were to make a Hurdish ncurses package today, we would
name it `libncurses4pi'. If that package was relinked against a
`libc.so.0.3' that has pthreads support, then we would rename it
`libncurses4i'. Then, if we added libio support, and changed glibc's
soname to `libc.so.6', we would rename the package as `libncurses4',
and simply use the same binaries as the Linux version.
If, later, ncurses grew some Hurd-specific functionality, we'd name it
`libncurses4h', and maintain it separately from the Linux version.
These conventions will allow every hurd-i386 user to keep their old
packages around as they make the transition through all the scheduled
libc ABI changes, and possibly even back into the `i386' architecture.
Comments are appreciated... especially from those who can point out
technical difficulties in my plan, improvements to it, or affirm its
effectiveness.
Whew. My head hurds.
--
Gordon Matzigkeit <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/)
[Unfortunately, www.fig.org is broken. Please stay tuned for details.]
Reply to: