Longtime lurker here. Overall I think this is an excellent idea.I can validate that there is use for this approach, since it parallels in many ways the roll it yourself method for maintaining a small embedded "baked" distribution currently used by a commercial product I work on. Once the system is installed there is no need (short of a forklift upgrade) to manipulate packages. I think many systems will share this trait. If I understand correctly, Emdebian just got a whole lot more interesting to me, since it would allow me a path to apply it to a project that already uses an embedded baked root filesystem, without adding much overhead.
On 4/13/2010 4:12 AM, Neil Williams wrote:
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.
Forgive my ignorance (I lurk, but I admit I'm not up to speed with how things currently work..), but I have a question. Would the scripts (preinst, postinst...) get run once by some part of the emdebian toolchain process (multistrap?) that builds the baked root filesystem? Or would the developer need to craft some of the preinst/postinst actions on their own (such as creating runlevel links, etc.)? I ask, since in our approach, the preinst scripts are converted into python scripts that distill down to the essential steps needed to install the package and are run on the expanded root filesystem. This is one of the big drawbacks to the roll it yourself approach I currently have to maintain, since I have to adjust the scripts every time an upstream package changes if they do something different or new.
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. 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. 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. 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. Comments?