Debian GNU [was: smarter way to differ architectures needed?]
[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 <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
Reply to: