Comment 11 for bug 646901

On Fri, 01 Oct 2010 18:41:03 -0000
Steve Langasek <email address hidden> wrote:

> Ah. But in that case, because the unpack ordering is not guaranteed,
> you would need to reinstall *both* binutils and binutils-multiarch,

The unpack ordering *could* be guaranteed as multistrap handles each
package individually. It is conceivable that a method can be
implemented to specify such a sequence - probably as a config option.
e.g. the *order* of packages listed in "reinstall=..." could be
rendered significant.

> because the unpacked files could be from either package. You don't
> want to end up with /usr/bin/objdump.single identical
> to /usr/bin/objdump!

That isn't that much of an issue specifically for binutils - nothing
actually calls the .single variants - for binutils* itself, diverts
could mostly be replaced by Replaces: without problems. The issue of
preinst scripts and foreign chroots is wider than just binutils though.

> Long-term, I think multistrap shouldn't be ignoring the distinctions
> between essential/required packages and other packages.

Sorry, that forces multistrap backwards into the debootstrap model and
that just isn't useful. Multistrap needs to work principally for foreign
chroots - it's use with pdebuild-cross for cross-building chroots and
other "native" chroots is secondary to it's main purpose. In a foreign
environment, there can be no useful division without leaving hundreds
of megabytes of .deb files in /var/cache/apt/archives/ completely
untouched or partially unpacked and retained anyway (so that the .deb
can be reinstalled or replaced files recovered), wasting space in the
unconfigured rootfs. That makes it even slower to unpack the
unnecessarily large rootfs and then install most of the packages when
all that is actually needed is to configure the unpacked packages with
nothing at all in /var/cache/apt/archives.

> The only
> packages you should need to dpkg -X are these; a three-pass dpkg -X,
> dpkg --unpack, dpkg
> --configure of the base system, followed by plain installation of any
> additional packages, would be reliable without any need to hard-code
> lists of packages that contain preinsts.

That is a backwards step when all that is actually needed is a sensible
way of unpacking foreign .deb's without running preinsts. dpkg-divert
is the biggest issue with doing that because files get replaced if
the .deb is extracted before the preinst can run.

Therefore, some way of manipulating diversions in a changed root
directory / path is sorely needed. Multistrap can easily identify which
packages contain the relevant snippets in their preinst scripts and
then store that information. The step I haven't had time to investigate
(because I'm moving house soon) is how to modify the files
in /path/to/var/lib/dpkg/ and elsewhere such that it looks to dpkg etc.
as if the preinst has successfully completed before that particular .deb
is extracted. All such manipulations need to be done using the tools
running natively outside the foreign chroot.

The other roles performed by preinst scripts may also need to have
implementations that can be executed from *above* the root directory of
the final system and by native tools, not the unpacked foreign ones.

Multistap's architecture-neutrality is a vital part of the purpose of
the package. If that means that certain packages cannot be put into
cross-building chroots due to their maintainer scripts, it doesn't
follow that the fix for that can afford to compromise the principal
role of creating foreign chroots using external apt to resolve complex
dependency chains from multiple repositories - which debootstrap
(or the debootstrap model) simply cannot achieve / was never intended to
achieve.

I'd rather just leave "native" support broken / retain the current
reinstall workaround. It's only affecting a handful of packages
currently.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/