On Thu, 24 Jan 2013 10:51:59 -0500 Andrew Bradford <andrew@bradfordembedded.com> wrote: > In building a root file system for armel Squeeze on an amd64 Squeeze > box, either with multistrap 2.1.20 or 2.1.15~bpo60+1, with normal > Debian debs (not emdebian debs), I find that extraction happens in > alphabetical order. This is not what I expected. It is necessary because the extraction happens separately to the configuration and the extraction is not done with reference to any preinst or other setup, it is a simple and direct unpack using dpkg -X / This is one of the main features of multistrap in that it avoids the need to package the .deb inside the rootfs and avoids the need to unpack the .deb on the target device. Most target devices for multistrap are embedded boards using NAND flash which is a lot slower at writing than a hard drive, so unpacking before copying onto the target device is a big, big win over debootstrap. It also makes the rootfs tarball itself a lot smaller which makes transmitting the tarball to the embedded device quicker. > It becomes an issue as I have build some non-debian debs with > alphabetical names that come before packages in which I want to > "Replaces" a few files along with creating diversions. My issue is > similar to bug 591518 [1] but not exactly the same. It is precisely the same - the preinst cannot be run, it doesn't matter about the extract order if the preinst is taken out of the calculation. > What happens is that my custom package gets extracted first, preinst > which would have setup the diversion doesn't get run, and then the > normal Debian package which my custom package "Replaces" gets > extracted. This ends with the normal Debian package's files > overwriting my custom package's files. Kind of the reverse of the > intention of my "Replaces" goal. Move the replacement of the files into the postinst. Package the files in a unique location (/usr/share/custom-package-name/) and then move them into place in the postinst. > In the multistrap code, it seems the packages get sorted by name before > being extracted. I've not delved deep into the code yet, but would a > patch that sorts by "Depends" be a reasonable improvement to multistrap? No, because sorting by Depends relies on having a full dependency resolver. Multistrap passes all dependency resolution on to apt, there's no point inventing another resolver inside multistrap and apt does not export the dependency tree in any usable manner. Extraction order is only allowed to be of importance when the preinst can be run - without the preinst, there's no point in second-guessing the extraction order. Alphabetical is better than unsorted (as it gives some indication of progress). It might be possible to organise unpacking by Priority as this information is more readily available and much quicker to sort. Even then, it would only be a case of unpacking the Required before the Important and leaving Optional and Extra as a single alphabetical lump because there is no sane division between Optional and Extra. This is closer to how debootstrap typically works but I'm not convinced that it would actually add any useful behaviour in multistrap. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgp2Lp1iSNyHx.pgp
Description: PGP signature