Re: smarter way to differ architectures needed?
Gordon Matzigkeit <gord@trick.fig.org> writes:
> >>>>> 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.
A system using ae as a vi replacement is a pain, its the most evil,
its worse than m$. "dpkg --purge ae" :)
> 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.
It is a new operating system, but it provides a linux compatible
layer, so linux becomes a subset of hurd (well, except for stuff not
yet written, like /proc).
> 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.
Why do we have an architecture field at all?
All we need are virtual packages for each architecture. All i386
binaries on "arch-i386" , all hurd package on "arch-hurd" or
"arch-hurd-i386" and so on. The "arch-hurd-i386" package would also
provide "arch-i386", "arch-hurd-all". The "em86" emulator to run i386
bins on alpha would also provide "arch-i386".
The dependencie information is far more flexible than the architecture
field and is more than capable to handle all cases of architecures one
wishes.
>
> 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.
You don`t need to download anything. They would be link farms anyway.
You would chose the directory descibing the selection of release,
arch, os,... that suits your needs best and download that, while
resolving the links therein. Also you could download the links and
automatically download all packages that links point to that you don`t
have already.
> 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.
Then you would go to /debian/linkfarm/source/... and only see source
packages. No need to waste your time with listing deb files. The
beauty of a wide linkfarm would be that every need could be present as
a tree on the ftp server.
> 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.
For that you need to drastically change the way deb files are
made. Its needed anyway, because people want to have 20 i386 debian
systems in a cluster together with a debian-alpha and an hurd-i386
system and want to share as much as possible over the network.
> 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, [...]
Yep, as I just wrote above, just my thinking.
> 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.
Well, kick out the architecture field altogether and its checks in
dpkg and your done. Shouldn`t be to hard.
> 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.
>
May the Source be with you.
Goswin
Reply to: