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 <[email protected]> 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*. > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
