[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Experiments with Crush

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

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


Neil Williams

Attachment: pgptd7TTpQ9A4.pgp
Description: PGP signature

Reply to: