[buildd-tools-devel] re buildd's resolver and package's build deps

[Steve Langasek]

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/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110228/77556925/attachment.pgp>