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

Adding chroot support to the dpkg functional testsuite (was Bug#580984...)



[ Moving this to the debian-dpkg where it is relevant, CCing
  debian-embedded for the cross-installation bit. ]

Hi!

On Mon, 2010-05-10 at 18:55:13 +0200, Raphael Hertzog wrote:
[ Bug in “dpkg --root” support. ]
> > > 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.
> 
> Right, but it should not be too difficult either. We could use debootstrap
> to create the chroot. We could make the usage of the chroot optional
> via the make variables used. $(DPKG_*) would hide the --root= and file
> based checks would be rewritten to have $(ROOT) prepended (it could be
> empty).
> 
> The major problem is how to automatically install the same dpkg version
> in the chroot... but we could keep that step manual and just have checks
> to verify that both are in sync.

The main problems with using debootstrap are that it's slow and it
requires network access. I had envisioned that at some point the
functional testsuite could be merged into the dpkg repo, and run
on “make check”, and would thus need to be lightweight.

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.

Another possibility could be to use something like busybox-static, and
install that in the chroot, then dpkg could be built statically and used
there, this will most probably be a bit painful for the build system.

regards,
guillem


Reply to: