Emdebian Baked.
http://lists.debian.org/debian-embedded/2010/04/msg00048.html
My comments about Emdebian Baked.
> 3. Advanced users needing ultra small and non-upgradable: Baked.
>
I don't think that "ultra small" necessarily implies Baked, though it
may be that may applications do require ultra small.
A fat embedded system still may require a complete and known filesystem
(apart from some config files). e.g. updating the fat system does not
use dpkg/apt to update some existing files. To update the system
software means updating the entire filesystem (even if there is only one
file that is different). Versions of system software are complete
filesystems.
system-version-1.2.3 = filesystem-version-1.2.3
system-version-1.2.4 = filesystem-version-1.2.4
system-version-2.3.4 = filesystem-version-2.3.4
I think Baked should be defined as a static debian filesystem with some
user customisations. It is em/debian in the sense that it is mostly
built from debian sources/packages, and the filesystem layout is debian,
and system scripts are debian, etc. It's just that the runtime features
of dpkg/apt are not required.
> 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.)
>
Again, this assumes Baked = Ultra Small. I don't think this is the case.
Some time ago, Crush was defined as the variant for ultra small. Is
that not the case now ??
Does it makes sense to have the following ??
Emdebian Grip (apt)
Emdebian Grip-Baked (static / non-debian-upgradeable)
Emdebian Crush (apt)
Emdebian Crush-Baked (static / non-debian-upgradeable)
> 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.
>
True for ultra-small. I think a fat busybox is ok to provide and
probably suitable for most embedded systems.
> 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.
>
Yep. Could use apt or dpkg to obtain a list of the all the files in the
packages, then rm all those files.
> 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.
>
Sounds sensible. Users could delete these manually in the the
multistrap hook, or post multistrap.
> 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.
>
Why not ??
To me, it's just a way to create a static Emdebian filesystem and using
a pre-seeded mechanism to configure some/all settings.
> 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.
>
It's always good to reduce the size if possible, even for fat systems.
As one example, a linux filesystem can be quite large, and if you were
remotely upgrading a device over a very slow network (e.g. 64kbps), a
large linux filesystem could take a very long time to transfer before
the upgrade can complete. It's not necessarily a show stopper, but the
faster the upgrade, the better the user experience.
Cheers, Brendan.
