Help identify packages that multiarch support will break
[ Bcc to -dpkg for info ]
since multiarch support in dpkg is on good track, it's about time to
identify what will break when people start using multiarch packages...
I have started filing a few bugs for some packages where I knew of
the problems but I need your help to identify other possible offenders.
Here's what might create troubles:
1/ Anywhere where the user might specify a package name, he should be able
to specifiy "package:arch" to cope with Multi-Arch: same packages that
can be co-installed (e.g. libc6:i386 and libc6:amd64 on the same
system). Those package names can also appear in outputs of dpkg-query
commands (dpkg -l, dpkg -S, dpkg-query -W).
2/ Any program that parses /var/lib/dpkg/status with the assumption that
there's only one entry with "Package: foo" is wrong. Uniqueness is now
only guaranteed on the tuple (Package, Architecture).
In general parsing the status file should not be done, instead you
should use dpkg-query.
3/ Any program that assumes the current layout of control files
(/var/lib/dpkg/info/<package>.<something>) will be broken (at least for
some packages) since the layout will change to support Multi-Arch: same
packages that can be co-installed.
You should use "dpkg-query --control-path <package> <something>" to
retrieve the path of the file. This has been introduced in dpkg 1.15.4
and is thus in squeeze already.
Do you know packages that will be affected by the above problems? Please
file a bug and usertag it with this command:
$ bts user email@example.com . usertag $bug + multiarch
Thanks in advance.
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)