At Extremadura, there were long, robust and detailed discussions around DEB_VENDOR and also discussions around the clear need for Emdebian to come in more than one flavour, in particular, one flavour that is maximally squeezed and has notable functionality changes from Debian and one that is lightly squeezed to retain equivalent functionality to Debian with an intermediate amount of shrinkage. I'm considering this general idea (developed from the content of the Gobby document we created): Emdebian will use TWO DEB_VENDOR settings: 1. emdebian-grip : no dependency changes, nodocs, increased TDeb granularity (one TDeb per locale per source package instead of the one TDeb per source package in Debian Squeeze). Inherently biased towards intermediate systems that just need a slimline Debian that builds natively and has no substantive or functional changes compared to Debian Squeeze. Emdebian Grip will be larger than the current Emdebian package set and include packages like perl (hence the expectation that Grip is natively built). There should be no real reason why Grip should not be available for all the currently supported Debian architectures (as of Squeeze). See also Compiling on Grip. 2. emdebian-crush : Various dependency changes with appropriate package replacements, busybox and all the benefits of grip. Intended for much smaller systems - the current set with further enhancements for even smaller installations, including getting the current GPE GUI package set below 64Mb installed and adding other environments like Maemo and something based on Qt. See also Compiling for Crush. Emdebian Grip and Emdebian Crush will use existing machine:variant support to select the appropriate packages. In most cases, developers looking at Emdebian Grip will build packages themselves - often on the same type of device that be running the packages - and host their own mirrors and repositories. Compiling on Emdebian Grip Once Emdebian Grip is installed, the intention is that whatever packages are necessary to allow native builds on the Emdebian device should be installable and supported. However, there should be no requirement that a device running Emdebian Grip must be able to compile software for a default install or typical usage. Initially, such packages will need to be hosted on local mirrors and repositories but it should be possible for Emdebian Grip to become an unofficial (and later, maybe, official) port of Debian and packages made available via wanna-build. (That may mean making Grip into a meta-architecture as there would be grip-i386, grip-arm, grip-armel, grip-mips etc.) Compiling for Emdebian Crush Unlike Grip, Crush is not expected to support compiling anything on the device itself. Devices running Crush will usually not be able to support even installing a compiler and build environment, let alone running a buildd. Therefore, Emdebian-Crush is closest to the current support which will be available in Emdebian 1.0 (based on Debian 5.0 "Lenny"). The full solution for Crush therefore depends on other infrastructure changes in dpkg and debhelper (to allow DEB_VENDOR to change the set of packages that are built). Crush will form the basis of other flavours of Emdebian built against uClibc - the current repository should be capable of supporting uClibc versions of Crush packages. Personally, I'd see no need for Grip-uClibc - if you want uClibc, you have a device that needs the extra-small packages only available via Crush. Current status: -------------- Grip is just an idea with outline support in the current tools. The main blocker is consistent "nodocs" support in Debian. In some respects, Dpkg/Classes ( http://www.dpkg.org/dpkg/Classes ) may be an alternative way to create packages for Grip - just dropping certain classifications of files upon installation, e.g. during testing. Crush is a formalised and improved version of what will be released as Emdebian 1.0 - largely it will be the result of the Code Audit that I'll start after Lenny is released. See also #480515 When will this happen? ---------------------- By Squeeze. Outline support will happen sooner - work will start on consistent handling of "nodocs" once Lenny is released and priority will be given to packages currently available via Emdebian 1.0 (i.e. the main package set for Crush). What happens after Squeeze? --------------------------- We could keep "Grip" and "Crush" or derive other names from the name of the Debian release after Squeeze (but those names are unlikely to be as apt as Grip and Crush are to Squeeze and Emdebian). Maybe keep Grip and Crush as codenames for the repositories in a similar manner to oldstable, stable, testing, experimental and unstable - but then that means having (and maintaining) grip-stable, grip-testing, grip-unstable, crush-stable, crush-testing, crush-unstable. Hmmm. This is going to need some extra manpower. How to achieve all this? ------------------------ I'm still working on getting the buildd.emdebian.org pseudo-package working properly - anyone can file bugs against that package name and the reports will come here but currently, the index page for the pseudo-package is broken due to bugs in bugs.debian.org and my hasty use of user-categories along the lines of ftp.debian.org that exposed the bug. $ bts show buildd.emdebian.org "bts: couldn't download http://bugs.debian.org/buildd.emdebian.org: 500 Internal Server Error" Instead you can use: $ bts select package:buildd.emdebian.org File bugs against buildd.emdebian.org as normal and I'll fix the Emdebian bugs page to link directly to the relevant bug reports. (The PHP/Soap interface is broken anyway so the bug page needs to be redesigned.) There is no need to continue using the usertags. I'm working on a bug helper for Emdebian that will know about cross-building logs, Emdebian patches and the like - including them automatically into the report via reportbug. When ready, it will be included in the emdebian-qa package. Depending on discussions here, the above content will go into a new page on the Emdebian website. (Yes, I'm also working on harmonising things like the ToDo lists on the website but if anyone fancies doing that first and submitting patches . . . . ) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part