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.
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
Reply to: