Re: 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.
Really? Truly? I will defer to the wisdom of those with experience with
debian, since I have none. But is it really the case that debian has no
better provision for this for dealing with different versions and
machine/os builds of the same package? That is a serious shortcoming.
> 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.
This is another wrinkle that the ideal package system would grok well.
Once we have some level of binary compatibility, there will be many
packages (hopefully the majority) that are not necessarily for a given OS,
but for an ABI, e.g. i386:libc.so.6. But still some other packages that do
kernel-specific things will depend on additional OS-specific ABIs and
perhaps work with only a particular kernel version. Ideally the package
dependency scheme would suffice to encompass these notions. The package
would be tagged with just its machine architecture, and then everything
else about "what OS is this for" would be expressed as specific
dependencies like "ELF libc.so.6[GLIBC_2.1]" (meaning "this package needs
an ELF shared library with soname libc.so.6 and version set GLIBC_2.1").
Other dependencies can say things like "linux-x.y.z syscall convention",
which would be a property provided by either a linux kernel package or a
syscall emulation package for a different kernel.
> 2) As soon as we get ``good enough'' ABI compatibility with Linux
This is an important goal. But please remember that our first goal is a
workable debian-hurd system, and goals like pthreads and libio will come
first and have their own benefits well before binary compatibility is
achieved. Getting the system usable first will get enough more users and
hackers bootstrapped and interested, that the actual technical goals in the
code itself can start to go faster. (Right now, I have at most a few hours
a week I can volunteer to hurd hacking; but there are just too many things
that need simultaneous debugging, and too few people able to try the hacking.
Someone should ask Mark Kettenis if there are any more like him at home. ;-)
Reply to: