> 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. ;-)
