I'd like to present some ideas I have for the future of the Debian package system. I should mention that I'm not a DD, and I've only recently subscribed to this list (though I've searched the archives), so if this sort of thing has been discussed already, or if these suggestions conflict with existing plans that I'm not aware of, I apologize. One thing that's always seemed a bit clunky in Debian is the number of mutually-exclusive binary packages built from the same source package which differ only in the set of compile-time options used. For example, look at emacs21 vs. emacs21-nox, or exim4-daemon-light vs. exim4-daemon-heavy. These provide a coarse degree of control over which optional features are included in a package, but what if I want, for example, a version of Exim that includes LDAP and PostgreSQL support, but not MySQL or Perl? This desire for a finer level of control over optional features immedately brings to mind the system of "USE flags" used in Gentoo. For those who aren't familiar with this system, a brief summary: you specify, in a configuration file, a string of keywords such as "alsa python ssl X" which identify optional features that should be enabled when building packages. For example, when you install Emacs, its X11 support will be built if the keyword "X" is present in your USE string; otherwise, it will be left out. IMO, this system has some maturing to do before it's really robust (which is part of why I don't use Gentoo), but the underlying idea is an excellent one, and I believe it can be adapted to the Debian way of doing things without requring major changes to the distribution (such as switching to a source-based model like Gentoo). What if we were to add Gentoo-like "feature keywords" to Debian source packages? For example, instead of having two binary packages "exim4-daemon-light" and "exim4-daemon-heavy", there would be one binary package, "exim4-daemon", having feature keywords "ldap, mysql, perl, pgsql". When you install this package, you specify the set of optional features you want enabled. At this point you're probably thinking, that means building 16 (2^4) binary packages for Exim, one for each possible combination. There are indeed 16 packages that *could* be built, but we don't actually have to build all of them: the maintainer chooses a few feature sets that cover most users' needs (in this case, the "light" feature set which includes none of the optional features, and the "heavy" feature set which includes all of them) and produces and tests binary packages for these configurations. Users can install one of these, or they can specify a different set of optional features, and apt (aptitude, synaptic, etc.) downloads the source package and builds exim4-daemon with the requested feature set. (In the latter case, the user should probably be warned that this is an untested configuration, and that the compilation may take a long time.) Depending on how the metadata and notation for specifying optional features are defined, "exim4-daemon-light" and "exim4-daemon-heavy" can either be directly interpreted as referring to configurations of the "exim4-daemon" package, or (more likely) be recast as dummy packages which depend on "exim4-daemon" with the appropriate feature set. This change would not require configuration changes in existing installations; if you're not taking advantage of the new functionality then you don't have to do anything differently. No change would be needed in most packages either; only packages which have several variants would need to be updated to use the new system, and even that isn't required if the maintainer thinks it wouldn't be a good idea. In essence, I'm proposing a way to have variant packages be created implicitly using feature flags, rather than being defined manually by the maintainer, to allow more fine-grained control of which optional features are included in a package. I'd be interested in hearing people's thoughts on the feasibility (and desirability) of making this change. -- Michael Paul mbp2@lehigh.edu http://www.lehigh.edu/~mbp2/
Attachment:
signature.asc
Description: This is a digitally signed message part