Re: libc soname conventions [was: libc6_2.0.106-0.1_i386.deb is released]

[Gordon Matzigkeit <gord@trick.fig.org>]

Hi!

[For everybody... if you got mail bounces from my address, it's
because my first computer's motherboard died, and my second computer's
power supply died.  Things should be remedied now.]

>>>>> Marcus Brinkmann writes:

 >> The better solution is to change libncurses' soname when we start
 >> linking it against different dependencies.  If the libncurses that
 >> was linked against libc.so.0.2 had a soname of
 >> `libncurses.so.4-0.2', and the libc.so.0.3 version had a soname of
 >> `libncurses.so.4-0.3', then everything would be fine.  The bash
 >> binary would depend on either `libncurses.so.4-0.2 and
 >> libc.so.0.2' or `libncurses.so.4-0.3 and libc.so.0.3', which would
 >> all have distinct filenames, and there would be no ambiguity.

 MB> Ah. I think this is comparable to the debian version numbering
 MB> scheme. We use an upstream version and a Debian version, for
 MB> example 2.01-5, where 2.01 is the upstream version and 5 the
 MB> Debian version.

 MB> In our case, we would have an upstream soname part and a Hurd
 MB> compatibilty soname part, right?

Exactly.  That's a very good way of putting it.

 >> Now, for development packages, we would make libc0.2-dev conflict
 >> with libc0.3-dev.  Then, libncurses4-0.2-dev would depend on
 >> libc0.2-dev, libncurses4-0.3-dev on libc0.3-dev, and everybody is
 >> happy again.

 MB> Ok. This requires only minor manual changes to the debian control
 MB> files.  However, auto.compilation is not easily possible with
 MB> those changes necessary.

Could you elaborate on the problem that you see that makes automatic
compilation difficult?  Perhaps we can find a workaround.

 >> If we don't use sonames to our advantage right now, we're going to
 >> have to introduce a lot of cruft into the Hurd's shared library
 >> resolution code.  I'm hoping we can avoid that mess, keep backward
 >> compatibility with ourselves, and still achieve reasonable
 >> compatibility with the Linux glibc ABI.

 MB> Well, the last thing would require that we switch back to Linux
 MB> sonaming at some point in the future. If I understood everything
 MB> correctly, we would maintain our own sonaming (with two parts,
 MB> upstream soname and glibc soname) for hurd library packages,
 MB> until we have a glibc ABI which is identical/compatible to the
 MB> one used by the Linux people, and then we could drop our
 MB> additional soname part and stay with the Linux way to do it?

 MB> If I did not understood correctly, you must explain how we can
 MB> get back to Linux sonaming...

You have understood perfectly.  When a given library no longer depends
on features that are different between the Hurd and Linux, then it
will simply use the existing Linux soname across all platforms.  From
the Hurd's standpoint, we will be ``upgrading'' to the new soname;
from everybody else's standpoint, we'll just be ditching some
unnecessary complexity in the Debian packaging.

My entire proposal is just a way of temporarily dumbing-down the
Hurd's sonames so that moving to Linux ABI compatibility looks like an
upgrade. ;)

Aside from your ``auto-compilation'' problem, I think that we have
agreement.  If anybody out there sees any more issues that need to be
discussed, please raise them.  Otherwise, I think we should formalize
the above into an official policy that Debian GNU/Hurd maintainers can
follow.

Thanks,

-- 
 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.]