On Sun, Jun 22, 2008 at 06:18:35PM +0200, Goswin von Brederlow wrote: > Hi, Hi!
> Given the recent renewed interest in multiarch I've been updating the > old dpkg multiarch patches. Along the way there are 3 general decisions > relevant to dpkg, apt and any other frontend that I would like to > finalize: > > 1) /etc/dpkg/architectures > ========================== > > There should be a conffile to specify the architectures (apart from > all and the primary architecture) the admin wants to use on the > system. The list should not and can not be hardcoded in dpkg as they > are not port but cpu or software dependent. For example newer ia64 > cpus can not execute ia32 code. i386 needs a 64bit kernel to run > amd64. Powerpc needs qemu to run i386. And so on. > > In the patches I used /etc/dpkg/architectures as conffile. The file > can be missing, in which case only all and the primary architecture > (the one dpkg is compiled for) are allowed. The file contains one > architecture per line and lines starting with '#' or empty are > ignored. > > I think apt should also use /etc/dpkg/architectures and download > Packages files from all binary-* mentioned therein (besides the > primary architecture) unless that setting is overridden in apt. I personally fails to see why dpkg should know about this information. >From my point of view, this is something needed for apt, so that it can select which package to install when calling apt-get install. OTOH, dpkg only need to install packages it is asked to install. Given that, the best is probably to add a configuration variable in /etc/apt/apt.conf. > 2) Syntax for specifying architecture > ===================================== > > At several places there might be a need to specify which architecture > is ment. Examples are triggers, depends and most importantly user > input. The current patches append the architecture to the package name > seperated by a slash, as in libfoo/i386. This collides with apt > versioning as in libfoo/testing. I'm not sure if that is acceptable or > not. > > The current patches also avoid the use of /all and /<primary arch>. > Input/output in dpkg should not change unless multiarch is actively > used. What about using a colon? I think I have already seen that somwhere. And it won't collide with epoch, as the epoch will always be after the slash, while the architecture will be before. So to install a package specifying both version and architecture, one can do: apt-get install libfoo:i386/1:2.3-4 > > 3) the new Multi-Arch field > =========================== > > The Multi-Arch field is a tri-state. The old patches use "yes | no | > <missing>" which is somewhat confusing at first glance. For lack of > anything better I've changed the code to use the following strings: > > abi: The package is a multiarch capable library. > - Multiple architectures of this package can be installed. > - The architecture of this package must match that of depending > packages. > + This involves modification to the packaging and might require some > package splits. > e.g. libc6 > > cmd: The package is a abi independent binary > - Only one architecture of this package can be installed at any > given time. > - The package works for depending packages of any architecture. > + No modification is needed apart from adding "Multi-Arch: cmd". > e.g. make > > no: The package has decided to not support multiarch > - Only one architecture of this package can be installed at any > given time. > - The architecture of this package must match that of depending > packages. > + No modification is needed apart from adding "Multi-Arch: no". > e.g. openoffice > > <missing>: We don't know about this package, default to "no". > > In status and available only "abi" and "cmd" will be recorded. > Specifying "Multi-Arch: no" is purely for maintainer to say "I have > thought about it and it doesn't make sense". To track the progress of > adapting multiarch. While I have to agree with the definition of the various state, I don't really like "abi" and "cmd". What about "library" and "standalone"? Or you may have better ideas. > 4) diversions (dpkg only) > ========================= > > If a "Multi-Arch: abi" package uses a diversion on a "Multi-Arch: > !abi" package we have a problem. The same diversion would be in > multiple packages then. I suggest we use "libfoo/i386" in > /var/lib/dpkg/diversions and add a new (optional) parameter > "--architecture <arch>" to dpkg-divert. The use of architecture would > be required for ""Multi-Arch: abi" packages only. Are their real need for allowing that? If not I suggest to simply forbids that. > > 5) meta files / maintainer scripts (dpkg only) > ============================================== > > If multiple architectures of a package are to be installed we need > multiple .list, .postinst, ... files, one per architecture. The > current patches use 2 functions (and some convenience wrappers) to > generate the location of a meta file: > > void pkgadmindirbuf(struct varbuf *, struct pkginfo *); > void pkgadminfilenamebuf(struct varbuf *, struct pkginfo *); > > All access to INFODIR goes through those 2 functions so there is a > single place that decides on the name scheme. Currently the > following is used: > > dir = /var/lib/dpkg/info/ > filename = libfoo.type for all and primary architecture > filename = libfoo.arch.type for other architectures > > Since '.' is allowed in package names I suggest using '_' as > sperarator at a minimum. I agree that the current implementation does not work for package with a dot in their name. If we switch to ':' to specify the architecture in an apt line, I suggest to also use it here. > > A more involved change would be to use the following: > > dir = /var/lib/dpkg/info/package/ > filename = arch.type > > Both replacing and removing of packages currently have to scan all of > INFODIR in search meta files belonging to the package in > question. With about 6k entries in INFODIR that causes a good amount > of readdir(), strrchr() and strcmp() calls that would be avoided. > > As for implementation I would create an /var/lib/dpkg/info/version > file containing 1 (old names) or 2 (new names). Upgrades could default > to format 1 and new installs could default to format 2. A simple > script could convert between 1 and 2 provided no multiarch packages > are installed. A case by case mode could also be done but I would > rather not. > I don't really like this solution involving a possibly problematic conversion. While having maintainer script whose name may or may not contain the architecture may looks confusing at a first glance, it's just a matter of time until all packages are rebuilt and use the new naming scheme. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
