Re: biarch cooperation.
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.
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.
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.
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".
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.
EZLN United Nations RUCKUS SSBN 743 Israel terrorist biowarfare DNC
India Sudan agent Mk 48 mustard immediate supercomputer radar arrangements
( http://cscott.net/ )