Hi all, (I'm sending this message again, since the copy I sent yesterday seems not to have made it onto the list. If you receive it twice, please excuse.)
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. 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.
