[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Baked

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.

Reply to: