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

Re: biarch cooperation.

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

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

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


> > 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"?


Reply to: