On Fri, 01 Oct 2010 18:41:03 -0000 Steve Langasek <[email protected]> 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/ -- multistrap needs to be updated for new apt and cross-tools in main https://bugs.launchpad.net/bugs/646901 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
