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

Areas of Emdebian to integrate into Debian

What do embedded people want to change in Debian and how does Emdebian
need to change Debian to make this work?

We have an opportunity to put these ideas to Debian to move us to the
next stage of integration with mainstream Debian. So, let's get this

To start things off, I'll make some suggestions (in no particular order
and there are numerous sub-tasks in each topic.):

0: Cross-compilers in Debian. Auto-built, auto-updated,
auto-synchronised, migrating into testing and stable using Debian
mechanisms to improve installability.

1: Grip processing by default within Debian. Making an infrastructure
which replaces the static list of packages which I have to manually
control so that packages are selected and automatically generate
Emdebian versions such that when foo migrates from libbar0 to libbar1,
libbar0 can be tagged for possible removal and libbar1 can be
automatically added to the list for Emdebian.

2: Multi-Arch-Cross support - replacing all of the hacks based on
current dpkg-cross with a variety of other changes, all based in the
Debian core packages like dpkg and apt. Some packages will need fixes
to avoid pitfalls currently managed by the -cross process. Some of
those changes need to go upstream.

3: Support for conditional build processes which can turn off particular
dependency chains / package options. e.g. busybox, avahi, cups, Qt.

4: Debian Installer option to use Emdebian Grip packages to create the
ISO and downloadable files to support an Emdebian Grip netinst
automatically after each release and point release.

5: Mirroring Emdebian Grip packages, by default, alongside Debian

Those are fairly well formed and achievable, with support from within

Harder ones include:

a: kernels. Conditional builds are one thing, constantly variable
configurations to suit each particular kernel variation for each of the
thousands of ARM boards (without considering all the other
architectures) are simply unachieavable in the current system.
Possibly, with cross-compiler support, there might be ways of building
an ARM kernel from the existing linux-2.6 source code with a
custom .config but the hard part is always getting the config right and
getting any patches to apply.

b: replacing coreutils / perl: We tried this, it took too much work and
there are no obvious solutions. Other systems do this better than we
can, so do we let this slide? (We are, currently, unless someone
steps up to do the work *after* Multi-Arch-Cross is deployed.)

That list probably includes what most people want from Emdebian and
overlaps with what Linaro are trying to achieve. Most will take
appreciable amounts of time and are likely to occupy Emdebian
developers well passed the next Debian stable release.

I propose that we commit to these objectives, subject to changes which
arise from discussions here, as the future direction of Emdebian. This
is not that large a step from where we are, other than that it would
become a public statement (to Debian and everyone else) that these are
the areas where Emdebian will concentrate the limited resources within
the project for the foreseeable future.

I'd envisage changing the updated website to include these objectives
in place of some of the outdated models which were based on the
emdebian-tools methods used for Lenny.

What else?


Neil Williams

Attachment: pgpHq_W1mXf8a.pgp
Description: PGP signature

Reply to: