Emdebian 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".

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:

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-riskstatically-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.