Re: Experiments with Crush
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.
Is one of the goals of Crush to be able to produce a small rootfs that
is not necessarily a Debian rootfs ??
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.
Brendan.
On 18/03/10 6:31 PM, Neil Williams wrote:
> On Thu, 18 Mar 2010 10:07:11 +1100
> Brendan Simon <Brendan@BrendanSimon.com> wrote:
>
>
>> Does this mean that gnome-vfs, xfonts-base, xorg, xorg-server are core
>> components for Crush ???
>>
> No, but they are among the packages that were released as part of Crush
> 1.0 and so deserve to be available. Upgrades are going to be hard enough
> without losing packages - the change in architecture already means a
> re-installation type upgrade. The reason they are in the shortlist is
> that they are candidates for changes in Crush to reduce their
> dependencies compared to Grip. Other packages in Crush won't be
> sufficiently smaller than their Grip equivalents to make it worthwhile
> cross-building them.
>
>
>> I hope not. There are some embedded environments, which Crush would be
>> extremely well suited for, that do not require any GUI libraries or X
>> servers.
>>
> Of course. Crush will take such packages directly from Grip, unchanged.
>
>
>> Think about a small http or ftp server. Maybe something that logs
>> temperatures (or some other real world signals) and the user can
>> download the logs via http, ftp, snmp, etc.
>>
> The packages involved in such support do not need particular changes to
> suit Crush - there are available packages that are suitably small and
> designed for such environments. I can't make them any smaller by
> cross-building than I can by putting them into Grip. Cross-building
> takes a couple of orders of magnitude longer per architecture. The maths
> is simple.
>
> Don't conflate Crush changes with design - packages that are in Debian
> and which are designed for embedded environments will NOT NEED to be
> cross-built for Crush because precisely the same package is available
> in Grip and no further reductions in size can be achieved. Such
> packages are always a better choice than packages that have to be
> "coerced" into being embedded-friendly. It's just that there's no point
> in wasting my time cross-building them. SQLite is a prime example. It
> takes ages and ages to get the cross-build right and I end up with ZERO
> changes compared to the package in Grip. No package size reduction, no
> extra removed files, no dropped dependencies, zero. Why cross-build it?
>
> Crush simply takes big Debian packages and tries to switch off various
> compile time options or mangles the maintainer scripts such that the
> package doesn't blow up when installed with busybox instead of
> coreutils. At the moment, that is all Crush can offer. (It wasn't long
> ago that Crush 2.0 was a complete impossibility, at least this way
> there is a chance, however slim.)
>
>
>> I think the crush core should be kept as minimal as possible.
>>
> It is as minimal as possible. So far, the list of packages actually
> being cross-built is down to a handful.
>
> The point is that a package is only shortlisted for Crush if it is too
> large or too awkward in it's Grip form.
>
> All other packages that were in Crush 1.0 will be drawn directly from
> Grip into the Crush repositories and those that Grip doesn't already
> have can be easily added.
>
>
>> Identify
>> the minimal packages and get the core building reliably such that Crush
>> can be released. Other packages can then be layered on top of the core
>> as the end application requires.
>>
> The core of Crush is Grip. What Crush then does is to remove coreutils
> and perl from Grip, replace with wrappers and busybox and then modify
> only those packages that absolutely have to be modified.
>
> The plan is to base Crush on Grip - any package that you want to use in
> Crush must either be available in Grip or be a Crush rebuild - such as
> the ones in the current shortlist. Rebuilds will all have their source
> package names changed (busybox-crush, gnome-vfs-crush) and their binary
> packages renamed (libgnome-vfs-crush-2.0-0) and Provides: Conflicts:
> Replaces: used as appropriate. That gives us full control over the
> packages that have been shortlisted for changes in Crush.
>
>
>>> I've prepared a shortlist of packages that will need functional changes
>>> in Crush:
>>>
> ... all other packages in Crush will come directly from Grip without
> being cross-built as there are insufficient resources to cross-build
> all of Crush due to the current complexities of cross-building in
> Debian.
>
> Maybe for Crush 3.0 or 4.0 then multiarch will be sufficiently useful
> to allow a fully cross-built Crush distribution once more. Until then,
> we either take 99% of our packages directly from Grip, or Crush simply
> *does not happen*.
>
>
Reply to: