On Thu, 18 Mar 2010 18:51:09 +1100 Brendan Simon <Brendan@BrendanSimon.com> wrote: > OK, it makes sense. > > I was actually thinking that Crush may be use an embedded libc (e.g. > uclibc) to get a very small linux root filesystem. That is probably already possible with the state of cross-building support currently in Debian; being uclibc, you will have to cross-build all packages in a chroot with uclibc available. The issue here is that a rootfs of that kind will tend to be *very* specialised and almost device-specific. There's little point me preparing such a system as a set of binary packages because every user would want something slightly different. Best example there is busybox - can anyone come up with a 'default' configuration of busybox that would suit more than half of such systems and not be considered bloated by unused options? busybox-crush will be quite big - nowhere near coreutils but a lot bigger than busybox can be. The packages that you would need for such a rootfs have already had cross-build support bugs filed as part of Crush 1.0 and many of those have already been fixed in Debian. There remain toolchains available and the cross-build problems are much less prevalent with "low level" packages that have few dependencies, such as those you'd be considering for this purpose. dpkg-buildpackage -a$arch now works without interference for the majority of packages you'd need for this purpose. Bolt onto that a call to `DEB_BUILD_OPTIONS="usecrush" emgrip foo.changes` and you can put the resulting packages into a local reprepro repository and use multistrap from there (for reproducibility). Essentially then, what I'm saying is it's going to be DIY. ;-) I'll fix bugs reported against multistrap and I'll fix emdebuild so that it is usable again (currently it is out of step with the Dpkg:: perl modules) so that the build + emgrip can be a single step with dpkg-vendor support. Beyond that.... (multistrap is also aimed at creating the chroot for the build in the first place - it can probably do most of that task already.) One idea is to make empdebuild a shell that calls multistrap to create the chroot, uses pbuilder code to pack it up, unpack it and throw away the used chroot etc, then uses emdebuild internally. I don't think that will be ready for Squeeze, unfortunately. The pre-requisite for all of this is ensuring that we have a plan for Crush that does not mean preserving the current (broken) cross-build behaviour. A lot of what we did for Crush 1.0 has to be ditched and reimplemented but that was inevitable anyway. > Is one of the goals of Crush to be able to produce a small rootfs that > is not necessarily a Debian rootfs ?? Small rootfs yes, but that's not likely to be possible for Crush 2.0. The binary distributions, Grip and Crush, are still Debian. (There was quite a bit of debate about whether Crush 1.0 was still Debian after removing perl.) Crush still doesn't provide kernels and a non-Debian rootfs could be something based on just a kernel and (another) customised busybox. Emdebian can provide some tools to assist but it's not directly part of Crush. The smallest system built from Crush will still have dpkg and probably apt. Smaller than that and Emdebian can only realistically provide tools, not binaries. > i.e. it is not intended to be able to apt-upgrade on the device itself. > An apt-upgrade would update the development environment, to produce a > new rootfs to load onto the target device. Multistrap support will go that way - although it's hard to persuade apt not to install itself into any system it is used to create. I cannot see that being possible in Crush 2.0, Grip 2.0 or Debian 6.0 (Squeeze). -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgptd7TTpQ9A4.pgp
Description: PGP signature