On 14/11/06 00:32:50, Guillem Jover wrote:
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.
Emdebian hopes for the same - although it's early days - and this is central to how the various emdebian schemes are being developed.
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.
Why not do both? We can do that. apt is intelligent enough to allow users to install the packages that fit onto their device. We can have one distribution that includes both the customised kernel and the full kernel. All it needs is a naming scheme - based on emN and the composite method.
http://wiki.debian.org/EmdebianMetaData
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.
This is a paraphrase of the combined emdebian method - implement the scripts and patches here to make it work, then take a working model to the dpkg and debhelper maintainers to implement upstream.
* Overriding Build-Dependencies for different purposes.
Build-Depends: huge, tiny
Build-Depends[embedded bootstrap]: tiny
This is more akin to the debian installer method - a dedicated field in debian/control that relates to "customised" builds. Personally, I think there's mileage in that for certain packages.
+ 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.
$DEBIAN_DIR isn't part of the composite method now being developed in emdebian. Instead, a system of patches is being implemented until such time as a method like this can be implemented upstream.
* Creating a Super-Essential subset of Essential.
(sub-essential or mini-essential? Super infers larger). Or instead, just dump essential completely (emdebian method).
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.
It is safe to trim down /usr/share/doc and translation files. This may be sufficient for a lot of devices - I'm expecting it to be adequate for my 30Mb iPAQ. It's also closer to the OpenEmbedded method.
Where individual package support exists, ./configure options can be specified in a patched debian/rules to omit specific build components. This is not going to be widespread but can be useful in corner cases.
* 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.
Is that a usable example? OOo isn't usable on some of my slower *desktop* machines, let alone embedded devices.
A better example may be gnucash. Although the current package cannot easily be split, the upstream code can be rehashed into separate modules if there is sufficient interest. I'm still working on a CLI for gnucash (ITP: #329676) that can open the way for a slimline Gtk front end using the same code: gpe-cash, designed specifically for embedded devices along the lines of GPE (although probably much larger than existing GPE applications). http://linux.codehelp.co.uk/embedded.html#gpecash
Work on those has stalled right now because of a disagreement with gnucash upstream and this is the real problem with splitting packages: upstream. Debian isn't going to be able to maintain split packages in the absence of support from their upstream. Splitting a package easily results in a fork. Some forks survive (epiphany/galeon), most do not.
I think there is a better method (the "get tough" method): 1. Broach the split with upstream and work with them if possible. 2. If not, dump the big package off smaller devices and create a need.3. This being free software, someone else will fill that need if there is sufficient interest. If there is insufficient interest, then no harm done anyway.
True, it takes longer but it results in more choice. After all, if this method was unusable we wouldn't have firefox/iceweasel etc.
It's also how Debian migrates from old libraries to new: basically tells maintainers and developers that either they upgrade their code or the package will eventually be dropped from Debian. This is exactly what Debian said to gnucash before v2 was released. It works - it concentrates the mind and provides the incentive needed to finish the job.
+ 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.
I like that.
Collection of alternative ways to solve some of those problems, although implying way bigger divergence, and thus frowned upon, just listed for completeness.
There will always be corner cases that require a customised approach. Slimming down Debian for any embedded device is not a task that can be 100% automated. (If it was, it would have been done by now.)
Emdebian has been discussing these issues for years, with varying success. Every method has involved some level of change upstream. No one method has promised to solve all issues in one go, a combined approach (as with the composite method) is the only realistic solution.
* Use 'Package-Type: edeb', to generate completely different
packages,
with a '.edeb' extension and different packaging policy a la
udeb.
.emdeb was not intended to do this.
+ Interfaces can be broken at will.
nor that.
- Massive divergence, and overhead at packaging level.
Only if packaging policy and interfaces are allowed to diverge. Automating the .emdeb buildd process to always be in step with upstream reduces the problem.
This could be a solution for really small embedded systems for example, or the normal udeb:s could be used instead.
But this already exists: ipkg and OpenEmbedded.If policy and interfaces are going to be changed that much, there is little point in calling it emdebian.
* Creating a replica of the debian/ dir a la emdebian way.
(That's the $DEBIAN_DIR method: see composite method instead.) http://wiki.debian.org/EmdebianMetaData -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpxpZ2S8ptQ1.pgp
Description: PGP signature