On Sat, 2008-01-05 at 09:48 -0200, Otavio Salvador wrote: > Tollef Fog Heen <tfheen@err.no> writes: > > > Hi, > > > > I've finally gotten around to fixing up my support for excluding bits > > of packages as they are unpacked. It can be gotten from > > git://git.err.no/dpkg in the master branch (sorry about that, it > > should probably have gone in a separate branch). > > What would be the usage scenario for it? Embedded devices? Yes, it was originally something that I set out to do at DebConf7 but Tollef came up with a better implementation of my patch. Once dpkg filtering is supported upon installation, I'll be looking at extending Tollef's work into filtering upon build so that I can further reduce the number of patches required to strip out unwanted components of Debian packages for Emdebian, in conjunction with support for noudeb, nodocs etc. dpkg-filtering upon installation isn't a complete solution for embedded devices because the device still has to download the entire package and unpack it - it is better to combine installation filtering with rebuilding the package upstream so that the device actually has room to unpack the .deb before starting filtering. Nevertheless, filtering is a powerful addition to embedded support in dpkg and Debian, especially for packages that contain lots of small files to be filtered out and where patches to remove those files are unnecessarily intrusive. (I'm thinking here of package files that Debian must include, due to Policy, but which Emdebian and others can actually do without.) However, for more powerful embedded devices, dpkg filtering may be all they need to be able to run normal Debian packages. Other uses include easier support for testing package changes such as splits and moving files between packages or replacing the static "Essential" list with a volatile list of packages selected during the installation. e.g. Emdebian already disregards "Essential" in order to reduce the size of the root filesystem - however the idea of "Essential" is still useful so Emdebian is considering how to implement a device-specific Essential list that is much smaller than the current Debian default. After all, apt doesn't care whether a package is Essential to your machine when running on my machine - it only cares about what is Essential to the current device. I can envisage testing for package splits by filtering out certain package components during install, seeing which applications actually need those components and thereby devising a new package split that operates on a *functional* basis instead of an archive basis. -- 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