On Wed, 2 Mar 2011 15:06:11 +0100 Raphael Hertzog <hertzog@debian.org> wrote: > 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). Multistrap can support that, it simply passes the package:arch to apt and the package listing is set by the user, so this shouldn't be a problem. > 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). I'll check other packages but multistrap is unaffected by the non-uniqueness in /var/lib/dpkg/status and other tools which might do this won't survive the implementation of multi-arch because they are based around the current dpkg-cross method. There might need to be temporary fixes. Most already use dpkg-query for this purpose. > In general parsing the status file should not be done, instead you > should use dpkg-query. Multistrap cannot use dpkg --unpack because multistrap is primarily working with a foreign architecture and therefore cannot allow the preinst to run. Therefore, multistrap needs to *create* /var/lib/dpkg/* from the various files exposed via dpkg -e. Multistrap needs to remain architecture-neutral - it will run 'dpkg --configure -a' inside the chroot if the architecture is native but the package processing and the creation of the data in /var/lib/dpkg/ MUST be architecture-neutral. Currently, dpkg does not support this, so multistrap has to do it instead. Multistrap cannot use dpkg-query because, at the point where this needs to be done, dpkg hasn't installed anything (in the directory which will become the root filesystem). Multistrap doesn't *parse* the status file, it *creates* it. Please don't assert that this is wrong until dpkg allows -unpack to work for foreign architectures by not running the preinst scripts. Preinst scripts need to be handled separately once the system can boot (either into a rescue environment and using chroot or directly). Note, this isn't actually affected by Multi-Arch - the foreign packages are not being installed in a Multi-Arch way, they are not being installed alongside native binaries. The foreign packages are downloaded and unpacked into a new, clean, subdirectory. This sub-directory *might* actually include packages from more than one architecture (neither of which needs to be the same as the external architecture), once Multi-Arch is in place, but the primary purpose is to create a root filesystem of an arbitrary architecture in an arbitrary directory with no direct relationship to the external system, other than that the external apt executable is used to calculate the dependencies and the external dpkg executable is used to extract the package data (using dpkg -X and dpkg -e). I'd love to be able to use dpkg --unpack with a directory but first, dpkg must handle *not* running the preinst scripts. Not just when the architecture differs but unconditionally so that multistrap can retain architecture-neutrality which is very important when trying to debug why a particular root filesystem fails to boot or fails to configure. Running the maintainer scripts needs to be a separate process, callable separately, from the creation of the dpkg metadata in /var/lib/dpkg/. Unpack should simply put the files from the package into a nominated directory, create the dpkg metadata in a path which starts with that directory and NOT run the maintainer scripts, ever. Then, foreign bootstrapping can be trivial. What will happen with maintainer scripts of Multi-Arch packages when installed alongside native packages? Why are these being retained if they cannot be executed? > 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. 1. Which packages currently show this behaviour? dpkg doesn't show any change in the --control-path setting for dpkg itself. 2. What are the changes in /var/lib/dpkg/info/* ? For Multistrap, every file in /var/lib/dpkg/ has to be created by multistrap, based on the data obtained from dpkg -e (basically the DEBIAN/ content). This data needs only to be sufficient that dpkg can correctly configure the packages once dpkg itself is able to be executed inside the new filesystem. As above, dpkg-query is useless in this situation - it has no data in the relevant location unless multistrap creates it. > Do you know packages that will be affected by the above problems? > Please file a bug and usertag it with this command: > $ bts user debian-dpkg@lists.debian.org . usertag $bug + multiarch Done. #616111 Bug CC'd. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpzzFjAl8gNM.pgp
Description: PGP signature