On Thu, 13 May 2010 07:21:26 +0200
Guillem Jover <guillem@debian.org> wrote:
> [ Moving this to the debian-dpkg where it is relevant, CCing
> debian-embedded for the cross-installation bit. ]
> On Mon, 2010-05-10 at 18:55:13 +0200, Raphael Hertzog wrote:
> [ Bug in “dpkg --root” support. ]
dpkg --root isn't used in the current Emdebian or cross-installation
methods - TBH it doesn't appear useful from the dpkg manpage:
--root=dir
Changing root changes instdir to dir and admindir to
dir/var/lib/dpkg.
(--root appears to be a shortcut to combine --admindir and --instdir
into one option)
The only options where this would be used, AFAICT, is --install but
that means running the maintainer scripts which is impossible when
building a cross-chroot.
Unless the new Multiarch code uses this method, it doesn't appear to be
something debian-embedded needs to rely upon.
Much more useful would be a way of 'installing' *without* allowing any
maintainer scripts (or any command within the chroot) to be executed.
dpkg in this mode would need to do everything it usually does to
maintain the status files (in another directory) and put the maintainer
scripts in a nominated directory, without executing any of them. If
--root did that, it would be useful. Currently, Emdebian has to
replicate this behaviour externally (e.g. in the multistrap package
which we use to replace debootstrap and cdebootstrap) - it works very
well but 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 - dpkg must simply
accept that there are some situations where the maintainer scripts
must not be allowed to execute, no exceptions, no complaints.
> > > > 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 but dpkg should still be able to create and maintain
the relevant status files and put the maintainer scripts inside the
chroot without calling them. dpkg should treat the package content as
if was all just data and had no executable content whatsoever.
It is not sane to run the scripts outside the chroot (amd64) and expect
the configuration to be appropriate for armel or mips.
This is the reason why Emdebian cannot use dpkg --unpack and has to
have a separate method involving dpkg -x and dpkg -e.
'dpkg --unpack and dpkg --root foo --install' insist on trying to run
the prerm/preinst which is just wrong.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Attachment:
pgpeFj31TKmUc.pgp
Description: PGP signature