Re: Bootstrapping a foreign architecture with multiarch
Hi!
On Fri, 2011-04-01 at 22:31:07 +0100, Neil Williams wrote:
> dpkg cannot be executed inside the chroot because it has not
> necessarily been unpacked at this stage, it certainly has not been
> configured. (dpkg is running from outside the chroot).
(An Essential package does not need to be configured to be functional.)
> Yet dpkg-query won't work with --admindir to operate from outside:
>
> $ dpkg-query --admindir /home/neil/code/chroots/natty-amd64/var/lib/dpkg --control-path libc6 postinst
> $
>
> Inside:
> /home/test# dpkg-query --control-path libc6 postinst
> /var/lib/dpkg/info/libc6:amd64.postinst
>
> /home/test# dpkg-query --admindir /var/lib/dpkg --control-path libc6 control
> /var/lib/dpkg/info/libc6:amd64.control
>
> $ ls -l /home/neil/code/chroots/natty-amd64/var/lib/dpkg/status
> -rw-r--r-- 1 root root 261652 Apr 1 21:46 /home/neil/code/chroots/natty-amd64/var/lib/dpkg/status
>
> dpkg outside the chroot is 1.15.8.10
>
> Do you want a bug report for that one?
No, because the external dpkg has no knowlegde of multiarch and the
new db layout, in addition you will trash the db in case there's more
than one “Multi-Arch: same” package instance installed when using an
older dpkg.
> Anyways:
>
> > Multi-Arch: same packages will use
> > /var/lib/dpkg/info/<package>:<arch>.<something>
> >
> > > 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.
> >
> > It's sufficient, you just need to know the value of the Multi-Arch field.
>
> True. I've got a change now which uses dpkg -f to check the Multi-Arch
> field of the actual downloaded .deb (independent of arch) and use that
> to detect Multi-Arch: same, then lookup Architecture in the same way,
> add that to the filename of the created maintainer script etc.
> for /path/to/chroot/var/lib/dpkg/info/*
If you are not going to install multiple instances of “Multi-Arch: same”
packages, then just keep writting the files as you are currently
doing, the next dpkg native run on that chroot image will
automatically upgrade the db layout. Which seems to be the less
onerous way to handle this. Otherwise you'll have to duplicate the
db layout handling, including format file, etc, and at that point I'd
say you are on your own.
On Fri, 2011-04-01 at 22:43:35 +0100, Neil Williams wrote:
> Further to this, --control-path doesn't include 'list' but
> $pkg:$arch.list files are created.
This was done on purpose, .list and .conffiles are internal files, the
correct interfaces to access the information is dpkg-query.
regards,
guillem
Reply to: