Feature Dependencies

Status

Details

This is a suggestion for an alternative dependency system for dpkg, replacing the existing version-based dependencies and solving the problems they do not.

Within Debian, when depending on a particular package you also often need to find out the version of the package that first supported a particular feature. Using debhelper as an example, if you need to depend on the dh_installman program you need to read the changelog to find out what version that feature was introduced in.

The problem becomes more difficult when features are introduced within a particular Debian revision, and in the multiple-distribution world impossible as different distributions could introduce features at different points. What feature was added in the Debian 2.7-4 package might have been added in the 2.6-3ubuntu2 Ubuntu package and backported to the 2.4-3woody2 stable package.

With feature-based dependencies, packages would instead declare a list of features they provide and packages would simply depend on a package containing a particular feature, rather than a version. An example syntax could look like: 

Package: debhelper
Features: dh_installman, dh_desktop, dh_gconf...


Build-Depend: debhelper:<dh_installman dh_desktop> ...

When taking bug fixes into account, the feature list of a particular package could grow fairly large so an alternative solution is to list features in a debian/features file instead.

Features could then be added at build-time by systems such as dpkg-shlibdeps to add information such as what versioned symbols a library package contains, what versions of build-chain packages it was built with and even what packages it depends on. 

Depend: libc6:GLIBC_2.3.3, libgtk2.0-0:builtwith-gcc4.0

Binary-only uploads would simply differ in the feature set they support.

Alternate packages

Another useful feature would be archives being able to offer multiple versions of the same package, with different feature sets. The feature set you desire could be specified using something like the existing APT preferences system. 

Package: *
Pin: feature gnome2
Pin-Priority: 550

System package

Feature dependencies could also be used to replace the current simplistic architecture handling. Every installation would have a system package that would provide a set of feature dependencies that the system supports. All packages would depend on this system package, indicating which features they require, rather than simply declaring their architecture. 

Package: system$
Features: i386, linux


Package: foo
Depends: system$:i386


Package: ps
Depends: system$:<i386 linux>

This would be an extra-ordinarily elegant solution to support "multi-arch" systems, those that can install packages from a number of different architectures. 

Package: system$
Features: amd64, i386, linux


Package: foo
Depends: system$:i386


Package: bar
Depends: system$:amd64

Packages would also have feature dependencies for the system they were built for, so multi-arch packages would need to have which architecture specified. 

Package: foo
Depends: system$:i386, libc6:i386


Package: foo
Depends: system$:amd64, libc6:amd64

All of these examples are against the control file stored in the binary package; when authoring packages debian/control wouldn't need the complicated syntax. You could disclaim or adjust architecture-specific requirements with a simpler syntax that hid the internal implementation of architecture dependencies. 

Package: foo
Depends: libc6, binutils [amd64], gawk [any]

Would become on i386: 

Package: foo
Depends: system$:i386, libc6:i386, binutils:amd64, gawk

dpkg: FeatureDependencies (last edited 2005-07-17 11:48:44 by ScottJamesRemnant)