On Tue, 10 Apr 2007 17:00:17 +0200 (CEST) jean-christophe.haessig@dianosis.org wrote: > It is often said that (some) debian packages carry too much > dependencies to be useful for embedded projects or sometimes drag in > annoying libraries. Most debian packages have too many dependencies for embedded use. > Making these dependencies optional would help people who try to > minimize their system image and still enable the people who need them > to use them. You must have upstream support for this to be realistic. See also: http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html http://rerun.lefant.net/checklib/ > How to do it ? 1. emdebianise the package to remove the easy stuff. [0][1] 2. inspect the output of ./configure --help for options to disable certain compile options or language bindings. (You've covered this step) 3. Remove entire packages from debian/control so that certain components (even if built) are simply not packaged 4. Edit the foo.install or foo.files content in debian/ to, again, simply not package bits that we don't want. 5. Repeat for each and every dependency until the one we want has a small enough list. 6. Pursue the process into the Essential packages and remove things like perl from essential. 7. Patch the pkg-config output and other autotools macros in debian/patches to drop the missing packages from the linkage output so that packages built against our version get the benefits. (As specified by vorlon.) > The dependencies I'm discussing are decided at compile > time. If one could build a program with every possible 'interesting' > combination of compile-time (enable or disable library) options (and > using ccache to speed things up), he could then create an archive of > binary patches against the most stripped down version of the binary. Insufficient - you will need to calculate the dependencies of the dependencies. e.g. libqof1 does not depend on libxml2, except that it uses libgda2-3 which brings in libxml2 for itself. Therefore, when building libqof1 for embedded use, specify --enable-embedded or remove libgda2-3 from the dependencies and libxml2 drops out too. This has to be supported upstream - the code that would have been used from libgda2-3 still has to come from somewhere and in the case of libqof1 it exists in the main tarball but is omitted if the (newer) libgda2-3 code is available. This is the problem that checklib is trying to solve. There is no way of making libgda2-3 "optional" for libqof1 without upstream co-operation - the patch would be massive and very difficult to maintain. Even when upstream for libqof1 (me) has done all that can be done to ensure that libxml2 is not a dependency (unless you specifically want the XML backend), checklib indicates that dependencies of the dependency can bring it back in. This is even worse in GUI packages. Gnome or KDE, makes not that much difference, both have looping dependencies. It's done to make it easier for desktop compilation. e.g. for deb-gview, I have just added GnomeVFS support without needing to add libgnomevfs to the dependencies because libgnome brings it in. Naturally, I've added it explicitly because I now link against it directly but there is no actual need to do so. I'm just trying to ensure that if libgnome is sorted out, at least my package indicates a usable dependency list. It was only recently that I noticed deb-gview didn't explicitly specify libglib2.0-0 as a dependency - libgtk2 brought it in instead. (The updated deb-gview is due for upload to Debian next week.) Part of the job of Emdebian is to provide an authoritative list of dependencies - the dependencies that actually matter - and to follow that trail all the way down to the toolchain, dumping Debian's 'essential' package list along the way. empath is a small step in that direction but a lot more is needed. [2] GPE has tried hard to prevent these problems (one reason why I am packaging GPE for Debian and then Emdebian). Take a look at an OpenEmbedded build and see how they have had to remove certain dependencies from the normal Gtk list. > Then, the binary the user calls would be some sort of rebuilder script See emdebian-tools - emdebuild will rebuild the package according to whatever patches have been implemented on the debian/* content. On an embedded platform, you won't be able to do any rebuilding - you need to cross-build and give the user binaries that run without patching. > which would pick the correct patches depending on what is really > available on the system. Ouch! What kind of embedded devices do you have in mind that can run such a rebuild script? Are you perhaps mistaking Debian for Gentoo? ;-) I don't know if there is an EmGentoo but Emdebian isn't about building, rebuilding or patching anything on the embedded device itself. > Many hard dependencies could be moved to > 'recommends' or 'suggests'. That will work sometimes but upstream has to support this kind of compilation - without a clear division in the source, you'll get this situation: AppA calls foo() which is in LibB. LibB starts processing foo() but foo() calls bar() which is in LibX. If calls to LibX have not been cleanly separated in the upstream source, (i.e. if bar() is not implemented in LibB in case LibX is not available) you'll get a seg fault. I've deliberately separated LibB from LibX to give some idea of how deep such calls can become with a GUI system. Imagine a call in gpe-expenses that calls libgpewidget1 that uses code from gtk which uses code from libglib2.0-0 which calls libc which returns to libglib2 and then to gtk which then uses code from libeventdb which then calls libsqlite0 and so on. [0] http://www.linux.codehelp.co.uk/emdebian/man/ [1] http://wiki.debian.org/EmdebianQuickStart [2] http://buildd.emdebian.org/svn/browser/current/host/trunk/empath/trunk/ -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp216FWYN9X8.pgp
Description: PGP signature