>>>>> Brederlow writes: B> It's not quite a port, it's a different operating system. :)
Is a system that uses vim instead of elvis a new port or a new operating system? My answer is neither, it's just an additional option for basically the same operating system. Seriously, though... GNU/Hurd is (or at least will be) a system that is ABI-compatible with Linux. The glibc, gnumach and hurd packages will be different, but every other binary can be the same, unless they *want* to use special Hurd features that aren't available under Linux, or are too Linux-specific (like things that use /proc, which we haven't written emulation for yet). The only reason why people think that this is a new operating system is because they are too attached to Linux. I love Linux a lot, and have accomplished many interesting things with it, but not enough to think that it's the *only* way of doing things. All that this is pointing out is that dpkg's idea of Architecture is too inflexible. People should only be forced to use ABI dependencies, not architecture strings, to name the dependencies of their binaries. I think then you'd find that only a small portion of Debian GNU/Linux actually depends on Linux. In many ways, using the GNU Hurd packages instead of Linux (plus associated glibc ports, which have different internals) should be like a cross between the Great X Reorganization and the move from libc5 to glibc. I know that these were both painful things for Debian to go through, but they've been done, we can learn from them, and make life easier for the developers of the next GNU kernel (the one that will replace the Hurd, if any) by preparing our distribution to offer alternative kernels. And no, I don't mean offering Linux 2.2 as opposed to Linux 2.0, but that is a minor instance of the thing I'm talking about. B> When I'm a hurd fan, I can just select debian-hurd and hit the B> download key (together with stabling symlincs) and I have my hurd B> for all my archs. B> Also a structure with the arch right at the front would allow B> downloading all arch-xxx stuff in a simple way. What if ``all arch-xxx stuff'' is just 20-30 packages, and you already have the other 4000 on your disk. I would be quite pissed off if you told me I had to download the other 3770 packages just because the Architectures don't match. Especially if I live in a place where I am charged an hourly rate for my Internet connection, I have a slow link, and I want to just try out the current sources. I want it to be possible for the Hurd and Linux to exist on the same machine, share a root partition and most binaries, and then just boot a different kernel and use a different libc at startup. The latest roadblock to my goal is the dpkg notion of Architecture. When that is fixed, we can move on to bigger things, like getting better glibc-2.1 ABI compatibility. B> /debian/link-farm/debian-hurd/... (just hurd stuff below this) B> /debian/link-farm/arch-i386/... (all i386 and all stuff below B> this) /debian/link-farm/slink/... (all slink stuff below here) Okay, now I'm understanding what you mean. Just ignore my above comments if you agree with them... I just want to make things more explicit. Certainly it is worthwhile to organize the tree as we want, but I don't think that it is a great idea to use separate scripts (though it may be a good prototype for the real implementation). I'd like to see native dpkg and dinstall support, and that will take some rewriting. I'd also like to see Architecture become obsolete, and replaced by something like: Depends: arch-i386, libc6, [...] for most packages, and: Depends: arch-i386, linux-libc6, [...] or: Depends: arch-i386, hurd-libc6, [...] for most kernel-specific packages. Very few packages (only the ones that use syscalls directly) would need to explicitly depend on linux or hurd themselves, because the libc6 ABI nearly completely insulates a package from the kernel. I don't think generalizing the behaviour of dinstall according to this would be too difficult. If we need to support legacy (Architecture-specified) packages, then we can add static rules that automatically convert the Architecture into the Depends as given above. But for now, we would have to figure out where to put the current linux and hurd kernel packages. In the current policy structure, linux and linux-libc6 are both part of Required, and so the Hurd has no place in arch-i386. That's not a big problem now, but it will get more and more frustrating as we get more compatible (i.e. hurd-libc6 doesn't exist yet, but hurd-libc0.2 still has a lot in common with linux-libc6), and want to duplicate less work. B> Thinking about it, it would also be nice to have B> /debian/link-farm/dists/slink/required/... and similar. :) Agreed. -- Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/) Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
