Proposal for handling embedded flavours in Debian
Hi,
I've been meaning to send this for a while, but have spent this time
thinking and polishing the proposal together with Daniel Stone. This
comes as a way to try to fix the problems we have faced while working
with maemo[0].
The proposal has as a goal, to try to merge as much changes as possible
(if not all) into Debian, thus reducing the delta that derivatives may
have to carry to be able to produce an embedded system. And thus
promote the embedded Debian effort into a real Debian subproject, and
not a parallel one which is what seems has been until now. With this
I'd not like to dissmis the amount of work and effort that the emdebian
folks have done until now, we just think that we should not be afraid
of pushing this into Debian proper, and that this can also make Debian
a better distribution.
I've seen some movement in the wiki lately, and while checking today
the list, found other alternative proposals (apart from the known
emdebian one). I'll be checking them a bit more thoroughly during
this week.
For some of the items, we've listed several solutions, we may have
missed pros and cons, or even different solutions altogether. So
please comment and discuss.
Also given this time of the release, and to not disrupt it, I'd like
to confine the discussion into this list, even if the proposal may
affect Debian at large, it can be discussed widely later on if liked
and desired, of course.
regards,
guillem
[0] <http://www.maemo.org/>
$Id: embedded.proposal 281 2006-11-13 23:47:11Z guillem $
Within the embedded world, there's two big targets, one which would try
to deal with really small devices with few MiB of storage (say 5-10 MiB)
which want to use a trimmed down and customized kernel, uclibc, busybox,
etc, and the consumer embedded systems, which do not have those tight
restrictions, storage and performance-wise. This proposal will not try
to address the former yet as it could be considered a more specialized
form of the latter.
Those are the current problems we face with an embedded Debian flavour,
and the overall solutions try to make it possible to merge back into
Debian any packaging and upstream changes needed for such flavour, so
to be able to reduce the delta in derivative distros to a minimal.
Legend: * possible solutions, + pros, - cons.
1) Huge binary packages with possible unneeded optional stuff.
Optional files which can be safely removed that do not affect
the interfaces that the package is providing, like doc, man, info
and locales.
* This should be fixed in dpkg, with filters, or exclusion lists.
Also this should not be used to exclude provided interfaces (like
a CLI), that should be done as in 4).
+ No need to modify packages, thus being able to use normal .debs.
+ The exclusion list can be selected globally, and changed when
generating the system tarball or filesystem image, which does
not need repackaging.
* Use of better compression methods, lzma uncompressing support is
planned to be included in etch, so it can be used in etch+1.
* For the case of info/, install-info would have to be changed so
that it regenerates the dir file from all installed info files,
then it could be considered as policy as the current doc/.
2) Heavy build options.
Build options not strictly needed to build the package, like
ldap or mysql support in packages.
* Those can be changed at build-time from debian/rules, using something
like 'DEB_BUILD_PROFILE=embedded' or 'DEB_BUILD_PROFILE=bootstrap'.
+ If done properly, this can be merged upstream, and kept in sync by
the maintainer.
3) Heavy Build-Dependencies.
Dependencies not strictly needed to build the package on such flavour.
* Some times this can be fixed by splitting the source package, like
moving some language bindings to an independent package, but this
solution is not general and cannot be applied in all cases.
* Introducing build profiles (the specific characters '<>' could be
changed, this is just an example):
Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !bootstrap>, tiny
+ Generic, it can solve other problems like bootstrapping.
+ Does not duplicate information.
+ Does not overload existing syntax.
+ Does not have the problem of mixed positive and negative arches.
- This could only be deployed in Debian on etch+1 and started to be used
on etch+2, that does not mean it cannot be used elsewhere beforehand
given different release cycles.
* This could be handled by using special strings as an architecture
in the Build-Dependencies. An example:
Build-Depends: huge [!embedded !bootstrap], tiny
+ Generic, it can solve other problems like bootstrapping.
+ Does not break current infrastucture, like sbuild.
- Overloading of existing syntax.
- Cannot specify positive and negative arches on the same
square bracketed section.
* Overriding Build-Dependencies for different purposes.
Build-Depends: huge, tiny
Build-Depends[embedded bootstrap]: tiny
+ Does not break current infrastrcture.
+ Does not have the problem of mixed positive and negative arches.
+ Does not overload existing syntax.
- This duplicates part of the original field, which has to be kept
in sync, although being side to side, it's easier to do than with
a complete different whole directory.
* Creating a Super-Essential subset of Essential.
Build-Depends-Minimal: tiny
Build-Depends: huge
+ Could probably help in the bootstrapping problem, although it's not
a generic solution.
+ Does not have the problem of mixed positive and negative arches.
+ Does not duplicate information.
+ Does not overload existing syntax.
- This could only be deployed in Debian on etch+1 and started to be used
on etch+2, that does not mean it cannot be used elsewhere beforehand
given different release cycles.
- The super-essential set would have to be self-contained, so a lot of
fixes would be needed in Debian.
4) Huge binary packages with exptected functionality.
Other programs expect an API, be it a set of binaries, functionality
from a library or modules from a given package. Even more if it's an
Essential one. So it's not safe to trim down binaries if there's
the desire to be able to use normal Debian packages depending
(implicitely or explicitely) on those ones.
* The proper fix for those cases, is to split such packages in Debian
itself. The main goal would be to try to reduce the essential set of
packages, or even base. But this does may not make sense at all for
things like OpenOffice.org.
+ It can benefit even normal users, by splitting unneeded stuff to
external modules, or by creating lightweight versions of the packages,
which is not uncommon in Debian itself. Examples, like -nox packages,
vim-tiny, the split of dselect from dpkg or gpgv from gnupg.
Collection of alternative ways to solve some of those problems, although
implying way bigger divergence, and thus frowned upon, just listed for
completeness.
* Use 'Package-Type: edeb', to generate completely different packages,
with a '.edeb' extension and different packaging policy a la udeb.
+ Interfaces can be broken at will.
- Massive divergence, and overhead at packaging level.
- No compatibility at all with normal Debian packages, so no way to mix
them.
This could be a solution for really small embedded systems for example,
or the normal udeb:s could be used instead.
* Renaming packages when changing interfaces.
+ Interfaces can be broken at will.
- Not being able to fulfill the essential set, and other required
Dependencies for external packages.
- Having to maintain the changed Dependencies for all other forked
packages.
* Creating a replica of the debian/ dir a la emdebian way.
+ Ability to change anything at will.
- Forking all software that assumes (rightly) that the debian source
package metadata is located under debian/.
- Forking all Debian packages, at this point it would probably make
more sense to just start from scratch.
- If using the same package names and extension and chaning the
interfaces provided (binaries for example), would make those
packages incompatible with normal Debian packages, so no way to mix
them.
- Low chances of getting this work in Debian and taken care by their
maintainers, even if merged in Debian, low chance the maintainers
will keep both in sync.
Reply to: