Emdebian 'shrunken debian scheme'
OK, here's the provisional text of the page that'll be going up as soon as
get the WML build working. The plan has plenty of room for fleshing out.
comments welcome. Action on some of the tasks even more so...
Some queries
1) can we get away without having emdebian-install targets?
2) Can someone who understands the buildds, madison, katie and dependency
migration in general comment on how much of it we need, how we should set it
up, and magration policy for keeping emdebian buildable.
3) what have I forgotten?
Some of this could probably be said more snappily as bulleted goals and
solutions - I'm afraid I tend to wordiness.
Emdebian and Debian
_________________________________________________________________
Debian is a fantastic resource with it's 10,000 packages and 11
architectures, but it's too fat for a lot of embedded and small-system
use. Below we describe the emdebian process for producing a version of
Debian that is smaller, but retains the as much that is good about
Debian as possible. The packaging system, the licensing, the
distributed development, the vendor neutrality, the multi-architecture
support, the guaranteed freedom, the availability of source, the build
system, the consistency between packages.
Unfortunately we can't just change Debian policy to mandate smaller
packages, or allow the removal of important documentation, as that
wouldn't suit most Debian users. But as soon as we make separate
packages from those in Debian we will get left behind and emdebian and
debian will diverge with emdebian failing to keep up. We need to have
a scheme that allows emdebian to stay in sync with Debian as much as
possible. To do this we need to keep emdebian package modifications in
each package, maintained by package maintainers as much as possible.
The initial modifications will be done by the Emdebian team in the
form of emdebian targets in the debian/rules. These modifications are
passed back to maintainers who hopefully can be persuaded to keep them
up to date for their packages.
This is a huge undertaking but fortunately we don't need to do this
for every package in Debian, only the relatively small subset that
most embedded/small systems need. Much of the process can be
automated, at least to a first approximation, and once the principle
is proved we can hopefully get the maintenance of the emdebian targets
mandated as part of Debian policy. However that's well in the future.
Right now we need to set up the system, make patches, persuade
maintainers and convince ourselves that we have a practical and useful
plan..
The Plan
This is the plan hatched at Linux World Expo, London 2003, by
(primarily) Daniel Silverstone, Wookey, Vince Sanders, Peter Naulls,
and Paul Hedderly, later modified by discussion on debian-embedded,
particularly contributions from Erik Andersen and Liberty Young. So if
you think it's rubbish you know who to blame. Critisism is welcome and
changes may well need to be made as we try things out.
Initially we will work just with Debian 'base' packages in order to
get a working infrastructure, and to keep the number of maintainers we
are dealing with down to a reasonable number. Once the principle is
established we'll include more packages.
Each (source) package will have emdebian-indep and emdebian-arch
targets, for architecture independant and architecture dependent
parts. These targets will be used by our build infrastructure. Most
will simply remove all the docs and other non-essential files such as
examples, unused locale information. For some packages changing
options to reduce the number of dependencies and/or make things better
suited to small systems will be in order. All packages will be built
against uclibc instead of glibc. Some secondary binary packages
probably need not be built at all.
All this means that emdebian will have a different dependency tree to
Debian. Managing this so that emdebian remains buildable at all times
could be tricky. Advice from release gurus is welcome. Ensuring that
build-depends are honoured for migration of a source package into
emdebian (unlike Debian proper's migration policy from unstable to
testing) should help, as should keeping our total number of packages
much smaller than Debians .
We need to
* Set up a build system (buildds)- Paul Hedderly volunteered a
system. Doing it for i386 first should make things simpler (and
quicker)
* Identify the initial emdebian subset of Debian
* Make emdebian targets for each package
* Persuade maintainers to incorporate the emdebian targets
* Build away and see how well it works.
* Document the process of creating an emdebian target for each
package
* Document the build system so that people can monitor it and
reproduce it
* Develop emdebian package policy to ensure consistency and
minimalism
Volunteers are needed for all these tasks, otherwise this scheme will
not get off the ground. Roll up, roll up.
Native compilation vs. cross-compilation
This is a thorny question. Debian is currently all natively compiled
because some packages are difficult to cross-compile. This is less
true than it was, and most of the things needed for emdebian probably
will cross-compile properly. For many developers cross-compilation is
how they expect to operate. On the other hand if people are using
binaries from emdebian they don't care how they got built so long as
they work. Native compilation works better for some architectures than
others - e.g. fast new ARM machines are available which make native
ARM compilation brisk. Native compilation means maintaining more
build machines and some of them will be slow, but it removes once
source of potential problems.
Starting with native buildd's, whilst working towards making emdebian
cross-compilable seems like a sensible approach, but there is room for
discussion on this point.
Documentation
There isn't any yet beyond this page. A detailed description of what
developers need to do is one of the tasks.
Wookey
--
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Reply to: