On Wed, 14 Apr 2010 09:19:51 +1000 Brendan Simon <Brendan@BrendanSimon.com> wrote: > 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. OK. I was working along the lines that smaller would make it easier to ensure that the system is properly configured. > 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. ... or deployed. At this stage, I've no idea how difficult it will be to statically replicate the results of running dpkg --configure -a for a given package set. I think this will become a lot clearer with experimentation and once the Squeeze release freeze starts. > > 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. Busybox itself doesn't use maintainer scripts - a full-fat busybox package for Baked could come from Emdebian Crush without further changes. > Some time ago, Crush was defined as the variant for ultra small. Is > that not the case now ?? Well, a Baked system would be slightly smaller than the equivalent Crush system. It's only a few Mb but it can matter when considering ultra-small. It's more a way of designating systems to be clear on what can and cannot be expected. > 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) Yes. I'll work that into the eventual webpage. > > 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. busybox-crush - once I've ironed out a few problems and uploaded the new version - will be available in the http://www.emdebian.org/crush repository as a full-fat bootable busybox configuration to replace the crippled default one from Debian Installer. > > 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. ... or (as mentioned later in the thread) use 'mv' to put them somewhere safe. This can be simulated with the current multistrap - for a foreign architecture. Possibly compare a native vs foreign and work out the desired static config from there. > Sounds sensible. Users could delete these manually in the the > multistrap hook, or post multistrap. Yes. multistrap does need some changes, e.g. to allow this kind of behaviour in native mode instead of assuming that it's OK to go and do 'dpkg --configure -a' after unpacking. Also, I think a lot of Baked users will not want a full size Debian base system (all packages with Priority: required) and this support is pending in 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. I was being pessimistic about the complexity of the static configuration. It may be easier than I expect, in which case relatively large package sets may work quite well. Any Baked installation capable of, say, running an X server would probably break in nasty ways. Simon has also hinted that various plugin methods could break spectacularly - I think he was referring to python mainly. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpCo8JPDeofW.pgp
Description: PGP signature