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:
pgp1okGtaCNkD.pgp
Description: PGP signature