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

Re: biarch cooperation.



Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:

> Goswin von Brederlow wrote:
> > "C. Scott Ananian" <cananian@lesser-magoo.csail.mit.edu> writes:
> > 
> > > On Fri, 19 Dec 2003, Thiemo Seufer wrote:
> > > 
> > > > AFAICS the control file needs only
> > > > Architecture: foo | bar
> > > > This is a bit of a misnomer, but it keeps things backward compatible.
> > > 
> > > Oops, I don't think I meant to limit the discussion to the control file.
> > > It seems like there are several points in the package system where these
> > > distinctions come into play:
> > > 
> > >  1) naming the package file.  I think naming should be by abi.
> > 
> > Package name must be unique across all archs, abis, flavours,

Unique is the wron word there I think. they must be the same,
identical. I fear thats quite the opposite meaning. :(

> > whatever. Anything else leads to a lot of work and complications.
> > Different names result in to many FTBFS erros for
> > multi-arch/abi/whatever systems.
> 
> I agree.
> 
> > >  2) requesting a particular variant of a package.  again, by abi.
> > >     the 'default' variant is set by the "kernel architecture",
> > >     which is an ordered set of compatible abi-groups (themselves ordered).
> > >     So, if I ask for 'apache', I first get apache!amd64 if that is
> > >     available, else apache!i686, else apache!i586, etc. 
> > 
> > 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, the architecture only one way.

That means a i386 program can call i686 libraries and vice versa. But
only a i686 cpu can run i686 and i386 binaries.

> > >  3) resolving compatible dependencies. This is done by "abi-group":
> > >     if apache requires libfoo, and I've got apache!i686, then
> > >     I look for libfoo!i686, else libfoo!i586, else ...
> > >     I know that libfoo!amd64 is not appropriate.
> > 
> > Depends on the other hand might have to be limited to abi
> > compatibility (libs and -dev packages). There is a difference between
> > arch and abi and the multiarch patches already handle them mostly.
> > 
> > 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.

> > The reason for this backwards resolving of abi dependencies is that
> > there are way less packages providing an abi than using one. Also lib
> > and -dev packages can be autodetected quite nicely and sanity checks
> > during build can be done. This also means an old, existing apache
> > package will work cleanly with a new enough libfoo.
> 
> Ok.
> 
> > > I think the control file ought to specify only the ABI.  The rest is known
> > > to dpkg/apt and friends.  That way future extensions (say, a transmeta
> > > chip which can emulate i686, ia64, or amd64, but prefers transmeta64)
> > > doesn't require further changes to the packages or to the archive;
> > > only dpkg/apt need to be told about the new "kernel-architecture".
> > 
> > The source/debian/control file should only specify that its limiting
> > depends to an abi (Abi: strict). Till now the correct abi is to be
> > deduced from the architecture of a package. Only if that is no longer
> > unique (as it could be for mips) a more informative Abi: ${abi} could
> > be used and set by dpkg-gencontrol.
> 
> I don't see why MIPS would be an exception. Why not always "Strict-Abi: yes"?
> 
> 
> Thiemo

If there is "Architecture: mips64" with "Abi: n32" or "Abi: n64" that
would be a small problem.

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.

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.

MfG
        Goswin



Reply to: