Re: New Multi-Arch field, architectures conffile and syntax questions
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
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: