[CCed to debian-devel, since people there are probably interested.] >>>>> Brian May writes:
BM> I agree. I think of the Hurd as being a replacement kernel for BM> Linux. Technically, I realize this is wrong (GnuMach is the BM> kernel) but I don't care ;-) I just repeat the mantra ``The GNU Hurd running on GNU Mach is a replacement for the Linux kernel'' which is technically correct. ;) >> 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. BM> I am not sure why you would want to say that something depends on BM> an architecture (ie major change involved in the way we think BM> about packages) when you can do everything required the existing BM> mechanism. Depends is designed to depend on other packages, it BM> was never meant to indicate kernel,arch combination is required BM> to install a package. I know that, and I think that design decision is the cause of all our problems, including the schism between GNU and Linux. Kernel and hardware architecture are really just some of a package's dependencies. Think about it: some packages depend on Linux and others don't. Some depend on i386 and others don't. Some depend on libc, and others don't. Some depend on Perl, and others don't. Some depend on nothing at all. All I'm trying to do is point out that the existing technology reflects peoples' stubbornness in giving more credit to hardware and kernels than is due. Ports other than i386 are *not* second-class citizens. Kernels other than Linuk are *not* second-class citizens. Don't get me wrong. Kernels other than the GNU Hurd running on GNU Mach are *not* second-class citizens, either. If hardware and kernels are not as relevant as people make them out to be, why do so many people call this system `Linux'? That's my only argument, and I'm not going to push my point. BM> Using Depends line instead of architecture only complicates the BM> matter of sorting packages into the Debian archive... No, that's the whole point of this exercise. People only *think* it would be more complicated. Once we get an implementation, and refine it, I think everybody will agree that it is simpler and more elegant. It would allow any Debian maintainer to create distributions that share arbitrary subsets of one another. Then, when the others upload a package, they don't specify what Just as I'd like to create a `gnu' port that corresponds only to the official GNU system (using Hurd instead of Linux, inetutils instead of netbase, etc), I'm sure that others have their own desires: * A `slink-gnome' port that has all the slink packages, but uses the latest GNOME. * A `pentium' port that has some Pentium-optimized binaries, but also uses many of the `i386' packages. * An `lsb' port that is the reference implementation for the Linux Standards Base. * A `glibc2.1' port, at least until it is clear that it really is more stable than glibc-2.0. Currently, the only packages that can be shared are the ones that are placed into `all'. This is the N=1 case. Marcus Brinkmann's (and I believe also your) temporary solution is to create `all-linux', and `all-hurd' as well as `all'. This is the N=K case, for an arbitrary constant K that takes a lot of work to modify (i.e. is hardcoded into dinstall and dpkg). I want to create the N=infinity case. If we have N=infinity, then really the only proper name for the superset of all those ports is `Debian GNU' (at least, unless we all decide to start depending on non-free packages, in which case the only proper name for it would be just `Debian'). Notice that this proposal is also a more general solution to the `staging area' idea that is currently in use. I'm talking about automating the process, and taking the burden of release coordination (and privilege) off of the FTP maintainers. Why should all ports have to release at the same time? Why should we not allow different ports to depend on different versions of the same package? Look at Red Hat. Because the above technology was not available to them, every time somebody wanted merely to *customize* the distribution, they had to fork their own (!). If Debian has the technology, then we would simply eliminate all the reasons for people to fork their own Debian. We've already done a good job of eliminating reasons to fork, such as giving people control over the packages that they care about. BM> I can't see how your method would work. What if the resultant deb BM> file will work on any i386 or if another deb file will work on BM> any Hurd system (but nothing else)? How would you specify this in BM> the source? How would the dpkg packager know to automatically BM> insert the build architecture into the depends line? I would BM> rather not have the packager do any fooling around with the BM> depends line, except where it is required (eg shared libraries). I'm not proposing specific solutions yet, because I think they will present themselves if we all agree that this direction is desirable. I also believe that we can do this work gradually, without having to break compatibility with packages that currently use Architecture. BM> Eventually, I think it should be possible for the Hurd to share BM> the same glibc source package as Linux, however, somebody else BM> will be have to verify this. It already does. I'm the one who made it work, and Joel Klecker merged my changes. BM> Hence it may be a bad idea to rely on glibc6 having a different BM> name on each kernel. For historical reasons, libraries built from the same glibc-2.1 sources have different sonames: `libc.so.6' on Linux, `libc.so.0.2' on the Hurd. This is because you Linux folks kept bumping up the soname, but us Hurd folks kept things the same. No value judgement here: Linux's libc simply developed faster than the Hurd's. And so, there is no such thing as `glibc6', only `glibc-2.0' or `glibc-2.1' (source release-based naming), or libc6 and libc0.2 (soname-based naming). Linux libc and Hurd libc will not use the same soname until both architectures provide the same libc ABI. Also, any Hurd-based port cannot share anything with the Linux-based ports except for `Architecture: all' packages (i.e. no kernel or hwarch dependencies), until our libc's have the same soname. I believe that's just a matter of time, and so I want to plan ahead so that the transition is easier for the Debian GNU/Hurd folks. Our (Hurd folks') work will resemble a cross between the libc5->libc6 transition and Great X Reorganization, all in one. With dpkg and dinstall's current notion of Architecture, I dread that work. If my idea of generic ABI dependencies is accepted and implemented, I'll be greatly relieved, and actually *look forward* to it. ;) Now I'll begin repeating my second mantra: ``There is no such thing as Architecture, only Dependencies.'' Are there any seconders? -- Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/) Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
