Re: thoughts on architectures

[utsl@quic.net]

On Mon, Feb 11, 2002 at 03:37:36AM +0100, Marcus Brinkmann wrote:
> On Sun, Feb 10, 2002 at 09:28:35PM -0500, utsl@quic.net wrote:
> > Like libc.so.4 on FreeBSD, soon to be libc.so.5? Not compatible with libc5 on
> > Linux. It's confusing, but I don't know any good way around it.
> 
> Well, then you have to include the OS-ABI field into the dependency name for
> all library dependencies.  As the information is easily available from the
> binary with objdump, this can be as automatic as the soname.  You have to
> make such decisions based on the universe you live in.  If you build a
> distribution that only ever has binaries from a single ABI tag, you don't
> need to include it.  But if you have different ABI tags you want to support,
> you mangle it into the dependency name.

I think you could say that a binary's environment is made up these things:

	1. processor type (i386, alpha, sparc, etc.)
	2. processor mode (64/32)
	3. kernel (linux, hurd, whatever)
	4. object format (ELF/a.out)
	5. object format subtypes or emulations
	6. libc

That ought to be sufficient to define a binaries requirements. I'd like to
see something flexible enough to deal with that much complexity, but not so
unwieldy that it can't be made to work. So I'll make my suggestion:

	1. Drop the Architecture field.
	2. Add two new multi-value fields. I'll call them Env-Provides, and
	   Env-Depends. Probably someone else can think of better names.
	3. Make those fields provide and depend on tags which are completely
	   separate from package names. This makes it easy to distinguish
	   what packages a package depends on from the environment it's been
	   built for. It also makes it easier to make an index of packages
	   for a particular architecture combination, and doesn't pollute the
	   package namespace with a lot of virtual packages.
	4. Drop keeping metadata in package filenames. Make them just a unique
	   string, assigned when the package is installed into the archive.
	   That gets rid of the need to add something to the filename to
	   distinguish i386 from sparc packages. Just use the Packages files,
	   and the control fields from the packages themselves. I'd be in
	   favour of going further: use one Packages file, and determine
	   available packages based on the tags your kernel and libc support.

It's a little radical, but I think it could work well.

> > Bear in mind that quite a few systems already support multiple kinds of
> > binaries,
> 
> My text was written with that in mind.
> 
> > Also, FreeBSD (and possibly NetBSD as well) uses the ELF OSABI field to mark
> > it's binaries.
> 
> The GNU/Hurd does it as well.
> 
> > Of course, dpkg doesn't know that...
> 
> dpkg doesn't know a lot of things ;)
>  
> > That should be correct. A distribution already is just a Package file with
> > references to files in the pool. No real change there. The difference would
> > seem to be in the generation of the Packages file.
> 
> Yes, exactly.  And you need some differences in the algorithm that decides
> when to compile a package from source for a given architecture (the pool
> might contain a compatible but inferior binary package).

But that's not a problem for the guy who makes the CD's.