Re: Bug#39227: apt: archtable does not support hurd
On Sat, Jun 12, 1999 at 02:52:57PM -0600, Jason Gunthorpe wrote:
> On Sat, 12 Jun 1999, Marcus Brinkmann wrote:
[sizetable]
> Well, if you have a nice patch that will purge that messed up
> configuration stuff then please send it my way :>
I will see what I can do. :)
> > What would this advanced functionality be?
>
> Basically something along the lines of what you are talking of, except you
> have missed an important point here.. Our system cannot handle multiple
> packages with the same version without a fixed (short!) arch string to
> differentiate them. You get package file name collisions, version
> collisions and it creates really nasty complications for any GUI you want
> to build for APT if you remove the function of the arch field.
I did not miss this point, I merely chose to not mention it because it is an
implementation detail. I don't want to repeat or continue the discussion
here, because this is thinking too far in the future, but it all sums up to
the following:
You can always get a smooth transition and backward compatibility by
maintaining the current Architectures with symlinks into, for example, a
package pool (or however this will be implemented). So, until we have better
support for it in our package selection tools, people would continue to
access packages through the usual binary-* trees. The place to implement
this first would be dinstall, which would be clever enough to find out if
the needed arch-depends (let's call them this way for now) are supported by
default in this architecture. So, grub for i386 would be installed in the
"binary-i386" and "binary-hurd-i386" tree by dinstall. A package which
doesn't depend on a certain processor but only on the Hurd would be
installed in all "binary-hurd-*" trees and so on.
> A purely dependency based system like you describe is pretty much
> unworkable, and doesn't really deal with people like Joey Hess who want
> Pentium compiled packages any better than the current system.
I am unsure if it should be "purely dependency based" (through the Depends:
field) or based on "Arch-Dependencies", but let me assure you that this fine
graduation is urgently needed. Only saving a simplified notion of CPU and OS
type just doesn't cut it. For example, the Hurd will be perfectly able to
run Linux binaries as long as they don't call kernel syscalls (until we have
an emulation layer for them), because the glibc is the same. This can't be
done in your approach.
Then, the pentium compiled packages can and should depend on arch-depend:
pentium, and eventually the user will not be limited to dinstalls binary-*
trees, but create his own on-the-fly from the big package pool (by
specifying the arch-provides of his system). This way, even Joey Hess should
be happy ;)
The system you propose is fast to implement of course, but it will trap us
again in other limitations. It does not really solve the underlying problem
(Manoj would probably call it half-baken). It's not scalable and not overly
flexible in my eyes.
> > > The table could look like:
> > >
> > > i386-linux i386 i486 linux i386
> > > i386-gnu i386 i486 hurd hurd-i386
> > >
> > > The first 3 columns are the same as we have now and the last two represent
> > > the OS and the Debian architecture string.
> >
> > I don't see why you would want to do this. Note that you already have
> > host_os and host_cpu, so you don't need to double this information in the
> > table. Then, "hurd" is NOT the right OS string for the GNU OS. It is "gnu".
>
> host_os and host_cpu are the 'gnu' versions of them, not the Debian
> Versions of them.
There are no Debian versions. There are some traditional defaults, butin the
end everyone uses what works for him. egcs package relies on i486, other on
i386. Some don't care. This is exactly the problem we are facing: People
still assume the Debian arch name is logically related to the architecture
of the underlying system. That's one of the problems I tried to solve with
dpkg-architecture (see the packaging manual).
> GNU might call the hurd the 'GNU OS' but we call it
> Debian GNU/HURD AFAIK.
No, we call it "hurd-i386". Please note how inconsistent our naming scheme
is, because i386-linux-gnu is called "i386". Of course, this can't be
changed any time soon for good reasons, but it's dangerous to rely on this.
[...]
> The strings autoconf pulls are just not good enough for a general purpose
> CPU and OS identification, particularly when Debian renames OS's (not to
> mention those version numbers..)
I think the autoconf names are quite the opposite, they are the best general
purpose arhictecture identification you can get. Everything else is a
simplification of that (merging several systems to one big class).
> So I hope you see now why I want all the fields and why.
Yes, I do. I also think that it is a step in the right direction. But then I
think that your idea is not radical enough, not going far enough. I think it
is the wrong place to put this information, too. apt should not be concerned
with this information (I also think that dpkg should not be. Both should
merely check existing dependencies/provides).
Well, we have now been a bit sidetracked from our starting point :)
This discussion is very interesting, but I wonder why you haven't joined the
thread on debian-policy when several people (Me, Gordon, Brian May and other)
have worked out the details of a proposal reaching more far back in April
(the proposal is not finished yet). Maybe it would be better if you could
take a look at the thread and comment there, so this discussion is not
hidden in this apt bug report.
What we should now be concerned with is a short time solution only. As
currently only one column in the table is supported anyway, it's sufficient
to address that (the Debian arch name). Also, both of us agreed on using the
complete host_cpu-host_os value of configure in the first columne.
I suggest that we do exactly that for now. It is trivial to extend the
table to carry more detailed information in the future if you really wish
to.
If you agree, I will make up a patch for that. I am still interested in
discussion of any long term solutions, but I would prefer to do this outside
of this special problem getting apt to run on the Hurd proper :)
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: