Re: biarch cooperation.
"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.
> 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.
> 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.
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 saw an earlier post on debian-amd64 about dpkg changes; perhaps the
> author of that could explain how their implemented code relates to
> my proposal above?
>
> I'm not a packaging expert by any means. Corrections are requested.
> What I was really getting at is trying to agree to terms for the
> different notions of compatible and incompatible library abis.
> Oh, and to steer discussion away from "subarchitecture" because
> the term was already defined to mean something else.
> --scott
So far packages have been renamed (libfoo -> lib64foo) when abis are
involved. This lead to several problems with broken depends already
and looks quite ugly in the control and rules files.
To resolve that problem we though of the above things. Compatibility
is denoted ina subarch table that describes (in rfc822 format) what
subarchitectures are compatible, what abi they provide and what
compiler flags they need. The architecture compatibility is already
used by dpkg and partly by apt. The abi compatibility checks and
having packages with the same name but different abi is being worked
on and looks good so far.
MfG
Goswin
Reply to: