My comments about Emdebian Baked.
I don't think that "ultra small" necessarily implies Baked, though it may be that may applications do require ultra small.3. Advanced users needing ultra small and non-upgradable: Baked.
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.
Again, this assumes Baked = Ultra Small. I don't think this is the case.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.)
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)
True for ultra-small. I think a fat busybox is ok to provide and probably suitable for most embedded systems.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.
Yep. Could use apt or dpkg to obtain a list of the all the files in the packages, then rm all those files.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.
Sounds sensible. Users could delete these manually in the the multistrap hook, or post multistrap.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.
Why not ??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.
To me, it's just a way to create a static Emdebian filesystem and using a pre-seeded mechanism to configure some/all settings.
It's always good to reduce the size if possible, even for fat systems.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.
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.