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 right. 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 packages. Those are fairly well formed and achievable, with support from within Debian. 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 ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpHq_W1mXf8a.pgp
Description: PGP signature