On Mon, Feb 28, 2011 at 07:12:00PM +0000, Roger Leigh wrote: > This was a pain when we changed the default inetd--every package > required updating. For others, e.g. mail-transport-agent, it's even > more painful (I thought an mta-default was proposed, similar to > virtual-policy above, but can't see it in use yet).
$ apt-cache showpkg default-mta Package: default-mta Versions: Reverse Depends: uw-imapd,default-mta ipopd,default-mta smartlist,default-mta psad,default-mta procmail,default-mta mutt,default-mta python-moinmoin,default-mta mdadm,default-mta mailutils,default-mta logcheck,default-mta inn,default-mta fwknop-server,default-mta fetchmail,default-mta drupal6,default-mta darcs,default-mta capisuite,default-mta bsd-mailx,default-mta backuppc,default-mta anacron,default-mta Dependencies: Provides: Reverse Provides: exim4-daemon-light 4.72-6 $ There are still a number of packages that declare a preferred mta explicitly - including some that declare a different preference than the Debian one! - but by and large these packages don't seem to be bothering anybody yet. > If we had a centralised list (apt could use them during resolving > directly), or a set of dummy default packages (as virtual-policy), a > package could depend upon just the virtual package, and this would allow > the default to be changed in a single place, pain free. I think that's a topic to be discussed with the apt maintainers. One of the ideas brought up when default-mta was implemented was for apt to sort by package priority for considering solutions to virtual packages, but it didn't appear anyone was willing to implement it. I don't think this is going to be as generally useful as you suppose, however. default-mta was the only case where this issue has ever risen to the level of warranting discussion on debian-devel, and it's already been addressed. More commonly, we have: - some virtual packages we really don't care which real package provides - some virtual packages for which there is no one correct default because different reverse-deps legitimately have different preferences - some virtual packages for which there is one obvious, persistently-correct default, so this doesn't buy us anything but a new transition So I guess the challenge is to get anyone to care enough to implement it. (Maybe this could make a reasonable GSoC project?) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature