[ 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
