Re: biarch cooperation.

[Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>]

Goswin von Brederlow wrote:
[snip]
> > > Package are requested by (sub)arch. Some of those subarchs (like i386,
> > > i486, i586, i686) have the same abi.
> > 
> > I still don't like this terminology. An ABI defines a binary
> > compatibility platform, and i386 vs. i686 aren't compatible, unless
> > restricted to the least common denomiator.
> 
> The ABI is compatible both ways,

Then an i686 package will claim to support ia32 ABI, but it will
fail on an i486 CPU, which claims to provide an ia32 ABI.

Your definition of ABI will provide different Application Binary
Interfaces under the same name.

> the architecture only one way.

Which means a i386 CPU with the emulation patches provides a
i486 "architecture".

Those terms are both grossly misnamed, and are usually used with
a different meaning.

[snip]
> > > When you have apache/i686 you look for libfoo. First you find
> > > "libfoo/amd64", but that only provides the amd64 abi so you discard
> > > it. Next one would be libfoo/i686, then 586, .... Any of those have
> > > ia32 abi and would suffice for the depends.
> > 
> > What will be done in the case of apache/i486? How do you prevent
> > it from trying libfoo/i686?
> 
> No. Only sytems capable of running i686 code would have
> "binary-i686/Packages" (and thus packages for i686) in their search
> path.

So an in686 try to find a package from "binary-i{3,4,5,6}86/Packages",
in descending order?

And the package files would be "<pkgname>_<version>_i{3,4,5,6}86.deb"
(if these are fully optimzed packages)?

[snip]
> > I don't see why MIPS would be an exception. Why not always "Strict-Abi: yes"?
> 
> If there is "Architecture: mips64" with "Abi: n32" or "Abi: n64" that
> would be a small problem.

N32/N64 are way too different for a common label. Btw, there can also
be ABI Variants (or subarchitectures, as you call it) for mips:

MIPS I, MIPS II, MIPS III, MIPS IV, MIPS 64, MIPS 64R2
                 MIPS 32, MIPS 32R2

which aren't in a simple upward compatible chain (MIPS 32* is the
odd one out). Further there are Application Specific Extensions (ASE)
like MIPS 16, MDMX, MIPS 3D; similiar to MMX and SSE on ia32.

> But currently binary-<arch> would have to be used to seperate
> different abis too, so that would make "Architecture: mips_n32" and
> "Architecture: mips_n64" with respective abis.

"mipsn32" and "mipsn64", I guess. It looks a bit odd, but any
non-alnum character may break some tools.

> Its the mips guys choice though. You figure out what you want/need/can
> patch. Having 3 archs is easiest even if it sounds off.

I don't think its off.


Thiemo