+++ Dave Martin [2011-03-11 11:20 +0000]: > Although it's not directly related to nano (which is useful in itself > as a miminal usable system) it could make sense to be able to generate > images with no built-in packager support - i.e., the packer must > effectively be run offline to generate the filesystem.
Yes. Emdebian calls this 'baked', and has some support for it - mostly in postprocessing the packages to remove all the stuff which is only needed for package-management. http://www.emdebian.org/baked/ > There's also > the possibility of keeping the packager information outside the main > tarball, so the filesystem can be modified/updated offline after > creation. Yep - and so long as you have cross-installing working. The problem is that whilst apt has always had excellent suppport for 'install things over there, and keep the database somewhere else', maintainer scripts have no way of being pointed at a sub-dir, so have to be chrooted. I don't think we currently have support for keeping the dpkg database outside the chroot but being able to run all the maintiner scripts in the chroot (also needs qemu, so no use where that is not available). We did show (Ed Bartosh did the work) back in 2005 that's it dead simple to add $(ROOTFS) all over all the scripts and have this work from outside (for most things - there are a few things that go wrong due to useing host config instead of target config), but it's an intrusive solution and we didn't try to push it further. It's nice because it avoids the need for qemu so you get genuine cross-installing. This issue highlights the way that we don't distinguish between install-dependencies and runtime dependencies in packages. A lot of package deps are actually only needed by the install scripts, so on an externally-maintained system are not needed - again making for much smaller images. I'd love to see support for these things in Debian, but both are intrusive - especially the former, so we'd need good justification for it. Perhaps Linaro can provide that... > As I understand it, debootstrap or germinate basically do the right > thing. All we would need would be to document the use of the existing > tools, and provide suitable ultra-minimal seeds (at the level of > busybox+libc only) and/or an ultra-minimal --variant for debootstrap. I don't think it's that simple - as explained above. But perhaps there is stuff to deal with this. I haven't been keeping up with all the new chroot and image-making tools. > If that's seen to be interesting, we should probably discuss it with > the emdebian folks-- there's a risk of reinventing what they do; plus > they certainly have tools which are useful for this. Indeed. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
