Re: Adding chroot support to the dpkg functional testsuite (was Bug#580984...)
+++ Neil Williams [2010-05-13 08:11 +0100]:
> On Thu, 13 May 2010 07:21:26 +0200
> Guillem Jover <guillem@debian.org> wrote:
> What I had in mind was for example to add a new --test option which
> would make dpkg pass a new environment variable (say DPKG_ROOT_DIR) to
> the maintainer scripts denoting the root directory and just avoid
> doing the chroot() call. Care would need to be taken to use the
> correct built backends, though. This option (if properly renamed)
> might also be useful for cross-installations, perhaps. Although
> package maintainer scripts would need to be accomodated (if possible
> at all) to make called programs operate on the different root path,
> which might uglify them quite a bit.
It might, yes. Ed bartosh did a load a tests a few years back which
showed that simply putting $(ROOT) on the front of nearly every path
in maintainer scripts made cross-installing/configuring work pretty
well, whilst still using build-system tools binaries. But as you say
this does involve a lot of uglification which is why we never tried to
get it pushed into every package in Debian, even though it is a nice,
simple and practical improvement. There are a few pathological cases
(where tools use implied local paths) which cuold go wrong.
> ...it would still be better if dpkg understood that maintainer
> scripts *cannot* hope to run inside a foreign chroot, ever. No amount
> of prefixes or hackery or magic will make it work
I'm not sure I agree with this unqualified statement. Simply using
qemu-static in the rootfs image makes dpkg --configure -a work just
fine for the fairly simple rootfs images I've tested it with.
This option is not available for all situations (target arch not
supported), and it doesn't work for everything (anything mono-y
currently dies), but it can work quite well.
I do agree that the ability to stop scripts (especially preinst
scripts) running is very useful for cross-installing.
> > > > > I think this feature deserves a non-regression test given how
> > > > > seldom it's used in daily usages by the developers.
> > > >
> > > > That would imply adding the infrastructure to create a chroot,
> > > > which might be nice to have anyway to test dpkg w/o affecting the
> > > > installed system, but still, I'm not prepared to do this right
> > > > now.
> > >
> > What I had in mind was for example to add a new --test option which
> > would make dpkg pass a new environment variable (say DPKG_ROOT_DIR) to
> > the maintainer scripts denoting the root directory and just avoid
> > doing the chroot() call. Care would need to be taken to use the
> > correct built backends, though. This option (if properly renamed)
> > might also be useful for cross-installations, perhaps. Although
> > package maintainer scripts would need to be accomodated (if possible
> > at all) to make called programs operate on the different root path,
> > which might uglify them quite a bit.
>
> No. Cross-installation means that the package maintainer scripts are
> to be ignored under all circumstances and that there must never be any
> opportunity for any of the foreign package maintainer scripts to be
> executed, let alone discover where they are.
>
> Package maintainer scripts *cannot* be accommodated by a
> cross-installation
It doesn't work right now, but I don't believe we should exclude
changes which could let it work in the future.
> 'dpkg --unpack and dpkg --root foo --install' insist on trying to run
> the prerm/preinst which is just wrong.
Agreed (as things currently stand, and this will remain the case until we
have a robust method to run the right things in the right context).
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
Reply to: