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 <[EMAIL PROTECTED]> //\ 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.]