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

Re: Areas of Emdebian to integrate into Debian



On Sun, 3 Apr 2011 15:37:15 +0100
Hector Oron <hector.oron@gmail.com> wrote:

> 2011/4/3 Neil Williams <codehelp@debian.org>:
> > What do embedded people want to change in Debian and how does Emdebian
> > need to change Debian to make this work?
> 
> > What else?
> 
>  * Changes to Debian build tools (pbuilder, sbuild, piuparts, etc..)
> to support all of the items in your list.

Naturally. Getting the objectives agreed will make getting these
changes into Debian a lot easier.

I've put the basic list on the Wiki. Feel free to expand each topic
with examples of packages which would need fixes to support each
objective.

http://wiki.debian.org/EmdebianObjectives

>  * Add a field which allows a package to be cross buildable (that
> might be delayed until we gain support for all that in Debian)

I'm not sure about this one. I think every package should be assumed to
be cross-buildable until proven otherwise. Many packages will never get
such proof because nobody is sufficiently insane to try and cross-build
LibreOffice for embedded devices. However, in the vast majority of
cases, the upstream packages DO cross-build. It is our Debian
packaging and infrastructure which breaks the cross build or which
doesn't make it easy to cross-build *and* turn off certain configure
options. Many packages had their packaging fixed as part of the Emdebian
CodeAudit alongside Lenny. Now we need to fix the infrastructure - which
basically means replacing dpkg-cross with Multi-Arch-Cross and this
is an ideal moment to get much tighter integration with Debian. 

Equally, there are plenty of packages which can be cross-built but
which end up no different to the existing native builds. So whilst
cross-building would be useful for bootstrapping a new arch,
cross-building these packages for supported architectures just wastes
time.

I think we need to concentrate on getting conditional build support
into packages which give us the most benefit. e.g. by dropping the
largest range of unwanted dependencies and turning off features which
make no sense on an embedded device.

*Then* we also need to concentrate on getting packages into Debian
which both cross-build and provide limited functionality or lower
resource limits to bring in real choice. I'm thinking here of sets like
GPE. There are other sets of packages out there which have lower
resource requirements than their GNOME or KDE equivalents. These are
the packages which *must* then cross-build.

An example of this, currently, is the argument in Debian about the fate
of ifupdown. Some want to replace it with network-manager. Ummm.....

I've had my 2cents on that one - others may want to chip in too, before
USB networking ends up depending on having dbus and WPA encryption
dependencies installed, or worse, Python.

http://lists.debian.org/debian-devel/2011/04/msg00067.html

>  * Regarding kernels...
>     We could easily setup an autobuilder which cross compiles kernels
> and place the packages into emdebian.org repository, but we need to
> agree what we want to support, probably a cross built version of
> Debian kernel package with extra configs they do not enable?

How many embedded devices can actually use a reconfigured but otherwise
unpatched vanilla kernel? Balloon cannot. It takes time to get
board-specific patches into the mainline kernel - time that many
embedded developers do not have. (Time that our Debian kernel team
don't have either.)

In many cases, I suspect it would be a case of turning off config
options rather than enabling more but the major problem is in the area
of patches, not configurations.

There's a completely different argument here about why we *have* so
many variant boards which need varying kernel support. Kernel people
aren't happy with the constant variability of board-specific support
systems. Personally, I question whether each individual board needs to
have a bespoke config supported by bespoke patches which conflict with
other bespoke patches for other similar boards, so I'm with Linus on
this one.

https://lkml.org/lkml/2011/3/17/492

Recently, balloon added support for having a single kernel for multiple
board configurations and handling the results via the vmlinuz.cmdline
support. That would seem to be the way forward to me because then we
could have a single set of patches which enable everything (even if not
present on a particular board) and then rely on the specific
commandline for that specific board to sort things out at boot. This
also lends itself to runtime kernel package upgrades and easier porting
of the patch set to newer kernels because more people are working on
the same patches, not their own.

> Do we
> want to build out of mainline kernels?

Do you mean mainline kernels with random patches applied elsewhere or
mainline kernels with patches we apply ourselves? Who is in control of
the patches and how are those updated for later kernels?

> Should we provide security
> fixes on those out of mainline tree kernels? Or should we just build
> kernel versions which are marked as long term support (2..6.32,2.6.37)
> and/or long term support for embedded (2.6.35)?

We don't have limitless resources. 

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpTzrj3WEQct.pgp
Description: PGP signature


Reply to: