emdebian development model
Hi all,
My understanding of the emdebian vision is that someone wanting to build
a linux device would:
1) Port the linux kernel to their hardware (including writing any
specific device drivers)
2) Select the _prebuilt_ emdebian packages needed to support their
application
3) Package their application as debian package(s)
4) Build a root filesystem using emdebian tools from 1,2,3
Once this is done you can upgrade on a package by package basis as you
would a normal debian system.
1) is pretty much the same whatever method / distribution you use.
For me the essential difference between emdebian and other contenders
(buildroot, open embedded) is that emdebian is based on binary packages
whereas the others are source based. Indeed buildroot doesn't even have
packages at all - its just a set of makefiles that let you create a root
filesystem as a big binary blob. I think open embedded does have
packages but I need to look more closely.
So emdebian is like debian rather than gentoo...
So in this ideal world someone putting together an embedded linux
wouldn't have to actually compile much stuff (just the kernel and the
application).
However the two things I currently believe get in the way of this vision
are :
a) The restricted set of architectures (crush is only available for ARM)
b) The limited set of available packages.
a) is being actively worked on so I won't say any more about it.
However I think there is a problem with b) because I don't see how the
currently small emdebian team can possibly be expected to provide all
the packages that may be required.
Unless I am mistaken crush 1.0 is currently a (small) _fixed_ subset of
lenny cross compiled with modifications where required to reduce
footprint (remove perl, ...). There doesn't seem to be any process to
allow contributions of "emdebianisations" of _lenny_ packages, only
_sid_ ones. But I'm not at all sure people developping a linux embedded
device want to be running sid any more than a system administrator would
want to run it on their production servers.
Sure nothing prevents me or anyone else emdebianising lenny packages in
a private repository but if everyone does this it will lead to lots of
duplicated effort and an overall lower adoption of emdebian since the
entry barrier is higher.
So I am envisionning emdebian-crush-stable, emdebian-grip-stable which
both consist a subset of lenny (same package versions) but where that
subset expands over time as people contribute to "scratch their itch".
So in this scheme:
* debian - defines set of packages that constitutes a stable release
and hence the maximum theoretical set of emdebian
* emdebian developpers - work on tools, infrastructure and core
packages and maintain repositories
* contributers - submit emdebianisations of stable packages.
I guess the problem with this scheme is that it will mean more packages
to migrate when the tools change...
Just my 2c
Martin
Reply to: