[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bootstrapping a foreign architecture with multiarch



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: pgpSbLgs5lfP9.pgp
Description: PGP signature


Reply to: