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] , 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.