Emdebian Baked
[ Preparing packages for Baked ] [ How would Baked work? ] [ Using Grip for Baked ]Pre-configured non-upgradable systems
Packages built or processed for Baked contain no maintainer scripts or other configuration scripts from Debian, just the runtime configuration support of the package itself. Baked is about making systems that do not need to be upgraded except by reinstalling the baked root filesystem - in effect, the system is like a cake - what is baked cannot be "unbaked".
Packages from both Emdebian Grip and Emdebian Crush can be further processed for Baked.
Emdebian Baked is intended for situations where you know, in advance, the precise configuration of the packages and do not want the packages trampling all over the configuration. (Packages that make changes at runtime would be up to you to handle.)
Emdebian Baked is an advanced system configuration - it will break lots and lots of assumptions and would 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.
The configuration is largely unchangeable without reinstalling a new root filesystem. 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 broken, reinstall an updated 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.
Emdebian Baked, gives us:
- Beginners and those needing an upgradable Debian system: Grip
- Intermediate users needing it smaller but still upgradable: Crush
- Advanced users needing non-upgradable versions of Grip or Crush: Baked.
How would Baked work?
Do It Yourself.
The "usebaked" support is available using emgrip to add 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, all are removed. It's a full use-at-your-own-risk statically-configured variant.
In addition, apt-grip has been extended to support processing packages from Debian for Baked. This is the model for Grip Baked. See Building Baked for more information.
If things break in Baked, you will need to fix it yourself.
Packages would be prepared 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 will provide only a few packages directly to support experimentation - at this level of configuration, there really isn't a sensible default set of packages that Emdebian can provide.
Users of Emdebian Baked would be expected to run their own local 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 would forcibly remove the dpkg and apt package files 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. Removals can be configured to move the relevant files outside the root filesystem for later use, 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 is set just by providing the relevant file in /etc/dpkg/origins and setting the DEB_VENDOR environment variable when processing the packages with emgrip.
Emdebian Baked might not be able to support a large number of packages per system - typical expectations are one or maybe two dozen packages at most, including the kernel.
As with other Emdebian variants, although the emphasis is on reducing absolute package size, devices where space is not an issue will still benefit from this approach by selecting those packages from Debian that have sufficiently low resource expectations and mixing those into the package set.
Note that statically configured is not necessarily the same as statically linked. Baked still uses shared libraries, unless packages are rebuilt as static and then processed for Baked.
Back to the Emdebian Project homepage.