New Multi-Arch field, architectures conffile and syntax questions
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.
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.
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.
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.
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.
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.
Comments? Objections? Suggestions?
MfG
Goswin
Reply to: