Re: Bug#39227: apt: archtable does not support hurd
On Fri, 11 Jun 1999, Marcus Brinkmann wrote:
> > There are two things being set here, the first is the arch string for dpkg
> > and the next is the byte sizes for the MD5 code, it is important to not
> > munge up either.
>
> Okay, I see. But why do you hardcode the sizes in buildlib/sizetable even
> in the default case (eg not cross compiling)? Can't the autoconf test not be
> trusted? I would suggest to access sizetable only when cross_compiling is
> "yes", and use the autoconf tests in all other cases.
<shrug> that is the way it was setup originally. (not by me) It sort of
makes sense, that is a good way of verifiying that the tables are correct
by enforcing their use.
> Note that "Debian architecture" is an _arbitrary_ string that is only
> connected to "host_cpu" because people wanted it this way. Now that we have
> Debian architecture names like "hurd-i386", we have to be more careful not
> confuse the Debian arhcitecture name with the name of a CPU or OS.
Why don't we just make it so that the architecture follows some nice well
defined rules intsead of having it as arbitary? To implement any more
advanced functionality that might be envisioned in the future APT does
need to know seperately the host_cpu and host_os values.
> There is no unique mapping from the values of host_cpu to the Debian
> architecture name ("i386" and "hurd-i386" have both "i386" as host_cpu), so
> it makes sense to me to use the unique $host_cpu-$host_os.
We can make APT compute this at runtime using some standard mechanism..
How about this. We haev a big ole table that takes the host_cpu-host_os
pair and spits out lots of different values..
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.
Jason
Reply to: