Emdebian Crush relies on dpkg-vendor support to actually implement the changes within the packages post-build. i.e. we cross build certain packages that cannot be handled any other way, then we take packages from Grip where the compiled code is OK but we want to slim down the package size. The changes made to packages are set using the DEB_BUILD_OPTIONS environment variable *at the time of the call to emgrip* and is entirely separate from the DEB_BUILD_OPTIONS that occur during the build (cross or native). The list of options passed to emgrip are configurable via /etc/dpkg/origins/emdebian-crush and/or similar files. As a result of the discussions about maintainer scripts and dpkg-divert, I'm considering a new build option to pass with Crush or a new variant of Crush - PRE-SEEDED CRUSH. Pre-seeded would enforce the complete and irrevocable removal of all maintainer scripts from all packages during the Grip process. This would be ideal for situations where you know the precise configuration of the packages in advance and do not want the packages trampling all over the configuration. (Packages that make changes at runtime would be up to you to handle.) This would be an "advanced user" configuration - it would break lots and lots of assumptions and would basically mean that your Emdebian installation is "Upstream+Debian patches". As such, there would be no need to consider installing dpkg or apt into the system - pre-seeding would be roughly equivalent to pre-baked. Just like moulding the clay and then firing it, once "baked", the configuration is largely unchangeable without reinstalling a new rootfs. Thereagain, without dpkg installed (and presumably with the dpkg emulation of busybox also disabled), this would be the expectation. Install once and run - if it turns out to be bust, reinstall a new rootfs. The device would simply not support runtime configuration of the underlying system - it wouldn't even necessarily support runtime *modification* of the underlying system, just the frontend that you design and implement yourself. It could be another variant for Emdebian - Emdebian Baked, giving us: 1. Beginners and those needing an upgradable Debian system: Grip 2. Intermediate users needing it smaller but still upgradable: Crush 3. Advanced users needing ultra small and non-upgradable: Baked. How would Baked work? ===================== DIY. :-) I'd add the "usebaked" support to emgrip to infer all the removals carried out by "usegrip" and "usecrush" as well as the complete and irrevocable removal of all maintainer scripts no matter what. debconf questions, preinst, postinst, postrm, prerm, the lot. It's a full use-at-your-own-risk statically-configured variant. (If you bust it, don't come moaning to me.) You'd prepare packages in an entirely normal way. If you still want glibc, use unchanged packages from Grip and then "re-grip" using a wrapper that calls emgrip with the extra option. If you want uclibc or some other variant, use the Crush methods to prepare a new package from the Debian sources, build it entirely normally and then post-process it with a similar wrapper. If you need packages from outside Grip, apt-grip will be able to call emgrip using the same options. e.g. busybox-crush is a full-fat busybox configuration that tries to be compatible with most of Debian. busybox-baked could be much smaller with all the long-options support turned off and various other tweaks to make the final busybox binary smaller. (IIRC busybox-crush is about 500kb.) Emdebian wouldn't actually provide packages necessarily - once we get down to this level of configuration, there really isn't a sensible default that Emdebian can provide. Users of Emdebian Baked would be expected to run their own repositories of baked packages. The expectation would then be that multistrap would work with such local repositories to impose the relevant configuration using device table files, pre-configured files to go into /etc/ and various other steps. One extra step for Baked would be that your final multistrap hook could forcibly remove dpkg and apt as well as the /var/lib/dpkg/ contents. Multistrap won't be able to do this for you (neither will debootstrap) because apt cannot be persuaded not to install itself. :-) When I say remove, it would be 'rm -rf /paths/to/dpkg/files' not 'dpkg -P' - leaving the system theoretically setup with dpkg but without dpkg or dpkg status files. This would gain several Mb of free space which could be advantageous for such a system. Baked could be set just by providing the relevant file in /etc/dpkg/origins and setting the DEB_VENDOR environment variable when processing the packages with emgrip. If this is suitable for anyone please let me know if there are other components of packages that should also be removed. Presumably such a system would not require md5sums files, symbols files or shlibs files. Many packages carry default files for /etc/ - I'd say it's worth keeping those and modifying them later if appropriate rather than removing them all and having to pre-bake everything. Emdebian Baked would NOT be expected to support a large number of packages per system - typical expectations are one or maybe two dozen packages at absolute most, including the kernel. As with other Emdebian variants, although the emphasis is on reducing absolute package size, I still think that devices where space is not an issue would still benefit from this approach by selecting those packages from Debian that have sufficiently low resource expectations and mixing those into the package set. Comments? -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpI6h6rY9FRQ.pgp
Description: PGP signature