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