[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#39227: apt: archtable does not support hurd



On Sat, 12 Jun 1999, Marcus Brinkmann wrote:

> > <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).

Well, if you have a nice patch that will purge that messed up
configuration stuff then please send it my way :>

> 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.

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.

> > 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. GNU might call the hurd the 'GNU OS' but we call it
Debian GNU/HURD AFAIK. I should have included one of the other rows from
the table too..

i686-linux i386 i486 linux i386

GCC likes to select different names for different CPUs in different
situations, the table is needed to correct for that. The OS name is
to deal with foolish things like:

nyquist{jgg}~#gcc --print-libgcc-file-name 
/opt/gcc/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.8.1/libgcc.a

And:

gsb086{gunthorp}~#gcc --print-libgcc-file-name 
/usr/lib/gcc-lib/i386-unknown-openbsd2.3/2.8.1/libgcc.a

<etc>
   
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..)

So I hope you see now why I want all the fields and why.

> 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).

I have no idea either, Tom Lee's did both apt and dpkg..

Jason


Reply to: