Re: Bug#39227: apt: archtable does not support hurd
On Fri, Jun 11, 1999 at 09:25:54PM -0600, Jason Gunthorpe wrote:
> 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.
But why providing a table at all? As I said, anyone who attempts
cross-compiling will have a valid config.cache for those values handy. By
specifying those values in sizetable, wrong values may be used silently (and
one will not notice because this is a very non-standard way to set those).
> > 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.
What would this advanced functionality be?
Note that the way dpkg handles architectures is about to become obsolete
anyway, and DPKGv2 will support a better way. Most likely, it will become
similar to the proposal made on -policy, where you use the dependency system
to depend on certain ABI's (like libc, proc-fs, linux-kernel-2.0, hurd-0.2
and so on). The architecture field would then not be needed anyway, and a
Debian architecture would merely consist of a default set of provided ABI
dependencies ("i386" -> "linux-kernel, libc6, proc-fs...")
To elaborate a bit further, for Debian, even seperate information for the
CPU and OS as you propose below are not sufficient for sophisticated
treating of architectures. For example, some programs depend on a linux proc
file system, some may not. Some may use system calls, some only use library
calls. So if the advanced functionality you envision is connected to a
better way to determine if a package would run on a given architecture, then
let me say that CPU/OS will not be enough to determine that and a better
proposal is already being worked on.
> > 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.
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".
Maybe I don't understand why you would want to do something like that
because I don't know what "more advanced functionality" you envision for
apt. But whatever this may be, it would most likely be wrong to make use
of such fixed tables as you propose for this purpose.
I am a bit confused now. The information you need is host_cpu, host_os, and
the Debian architectuer string. The first two are there, what you need is
the third. So a two column table listing
${host_cpu}-${host_os} debain_arch
would be quite sufficient. The third column is useless anyway for any
serious purpose. (nobody could tell me what it was intended for when I asked
around even in dpkg).
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: