Counter-Proposal: Architecture Versions and Architecture Features
Hi all,
Andreas Barth wrote:
> DRAFT - Subarchitectures for debian [0.1]
First, thanks for creating a prototype proposal.
I understand that the your proposed extensions to the Debian package system
are based on the concepts of "sub-archs" and "meta-sub-archs" (I'd call
these "pseudo-sub-archs" or "alias-sub-archs", though). I have already
proposed a more genereal extension based on "arch versions" (essentially
equivalent to sub-archs, except that an order is implicitly defined), and
"features". I'll explain it in more detail, because I think that a more
general approach would also be more flexible for potential future
requirements in the Debian package system.
Architecture Specifiers
-----------------------
An arch specifier may specify the exact base arch, arch version, and arch
features that are supported by a given system, or that are required for a
given binary package to work (with or without an emulating kernel).
Every base arch (alpha, i386, mips, ...) can, but isn't required to, have
one or more explicit versions (as I said, these are equivalent to
sub-archs). An arch version gets appended to the base arch name as
".<version>", the default version being 0. Thus, "i386" would be
equivalent to "i386.0", and subsequent versions could be "i386.1",
"i386.1foo", "i386.2", and so on. Arch versions are ordered
alphabetically, with higher versions including the functionality of all
lower versions, i.e. higher arch versions must be downwards compatible.
Example: "i386" = "i386.0" < "i386.1" < "i386.1foo" < "i386.2".
Independently, every arch can, but isn't required to, have one or more
special features beyond what the base arch version supports. A feature
gets appended to the arch name/version as "+<feature>". For "i386", there
could be features like "fpu", "mmx", "sse", "sse2", etc. A single arch
specifier can name any number of features, e.g. "i386+3dnow", or
"i386.6+mmx+sse".
Binary Package Files
--------------------
Binary package files shall have the full arch specifier in their file names
(see below for examples). Current packages with simple (traditional) arch
specifiers such as "i386" don't require special features beyond what the
base arch version supports, thus the extension is backward compatible.
"control" and "Packages" Files
------------------------------
In "control" files, the "Architecture:" field, as before, lists the
architectures supported by the base arch binary packages. Additionally,
more specific arch specifiers can be listed here. Binary packages will be
built for every listed arch specifier. Example:
Architecture: alpha i386 i386.6+mmx+sse mips
The special "any" arch specifier in the "control/Architecture:" field would
only build binary packages for the base archs.
The "Packages" file of a given base arch would, for every binary package
based on (but of course not neccessarily supporting) that base arch, list
the packages' exact arch specifiers in the "Architecture:" field. I.e.
although a binary package compiled for "i386.6+mmx+sse" probably will not
run on a real 80386 or Pentium 1 machine (disregarding any emulating
kernels), it will be part of the "i386" base arch nonetheless.
The Package Pool
----------------
Binary packages built for an explicit (non-base) arch version, or requiring
special features, like the fictitious "quake2" package mentioned below,
would be stored in the pool normally.
base arch's pool.
apt and dpkg
------------
There might be several methods for apt and dpkg how to choose which
packages to download and to install. Generally, binary packages for the
plain base arch will be downloaded and installed unless specified
otherwise.
The 'APT::Architecture' configuration option would specify the *minimum*
arch version and features that must be required by any package to be
installed. The *maximum* arch version and features supported by the local
system could be configured either as some 'APT::Architecture-Maximum'
configuration or '--arch' command-line option, or as some generic
'/etc/hwarch' config file, or it might even be possible to query the kernel
for this information.
Apt would then choose the binary package compiled for the highest
compatible arch version and the most matching arch features that fulfills
both the minimum and maximum requirements.
Examples:
Available packages in the fictitious pool:
(A) pool/contrib/q/quake2/quake2_0.2.1-4_i386.deb
(B) pool/contrib/q/quake2/quake2_0.2.1-4_i386.5+mmx.deb
(C) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+3dnow.deb
(D) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+mmx.deb
(E) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+sse.deb
(F) pool/contrib/q/quake2/quake2_0.2.1-4_i386.7+mmx+sse.deb
(G) pool/contrib/q/quake2/quake2_0.2.1-4_i386.7+mmx+sse2.deb
# uname -a
Linux gray 2.4.20 #1 Fri Apr 4 14:43:45 CEST 2003 i686 GNU/Linux
# cat /etc/apt/apt.conf
APT::Architecture "i386"; # minimum arch specifier
APT::Architecture-Maximum "i386.6+mmx+sse"; # maximum arch specifier
# apt-get install quake2
(chooses package D, acceptable fallbacks would be E, then B, then A)
# apt-get --arch i386.6+mmx install quake2
(forces package D)
# apt-get --arch i386.6 install quake2
(chooses package D, acceptable fallback would be E)
# apt-get --arch +sse install quake2
(chooses package E, no acceptable fallbacks)
# apt-get --arch +mmx+sse install quake2
(no acceptable packages, fails!)
Please note that it probably wouldn't make too much sense to build such a
lot of specially optimized binary packages like in the above example. I
just invented these for demonstration purposes. ;-)
Special-Case Proposal for "i386"
--------------------------------
If the above gets accepted, even though it might cause additional work, it
might be a good idea to rename the "i386" base arch to "ix86" or "ia32" to
avoid confusion. Otherwise, "i386" (AKA "i386.0"), "i386.1", "i386.2", and
"i386.3" all should mean 80386, so at least starting from .3 it would be
somewhat intuitive. Since I don't know whether other base archs currently
have needs for arch versions, what about their version numbering?
Julian.
Reply to: