[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Policy regarding virtual packages



Hi folks,

Following some discussion with Marco d'Itri about inetd, I'd like to
put forward some more general thoughts on virtual package handling for
some comments.

Currently, virtual packages (such as mail-transport-agent) cannot be
specified by themselves.  They can only be used in combination with a
non-virtual package which provides the default implementation.  For
example:

  Depends: exim4 | postfix | mail-transport-agent
or
  Depends: exim4 | mail-transport-agent

This means that

1) Each package depending on a virtual package must specify a real
   package
2) There is no central policy defining which package is the default
   implmentation--each package could specify a different default
3) Changing the default is a lot of work--every reverse dependency
   must be updated.

For the case of mail-transport-agent, this could be simply solved by
the creation of a mail-transport-agent-default package.  This would
be an empty package, doing nothing but providing this dependency:

  Depends: exim4 | mail-transport-agent

All packages wanting to depend on mail-transport-agent need only have

  Depends: mail-transport-agent-default

When exim4 becomes exim5, or some other MTA, only the
mail-transport-agent-default package would need updating.


For the new inet-superserver virtual package, there are potentially
over 120 packages which would need to add

  Depends: openbsd-inetd | inet-superserver

However, I feel that this is too many places to hardcode the
openbsd-inetd default (Marco d'Itri does not believe this is worth the
effort, but I personally think that it will potentially prevent a lot
of future effort).  Here, I think a means of specifying a
distribution-wide default is much better than requiring each package
to separately specify it.  For this case, I would like to create an
inetd-default (or inet-superserver-default) package, which would
simply be

  Depends: openbsd-inetd | inet-superserver

and all inetd-requiring packages would just use

  Depends: inetd-default

See http://people.debian.org/~rleigh/inetd-default_1.tar.gz
and http://people.debian.org/~rleigh/inetd-default_1.dsc


There are some other useful side-effects:

Custom Debian Distributions can easily change the -default package to
customise the distribution defaults.

Example: Scott Remnant recently blogged on -planet about the "upstart"
init/cron/inetd replacement being developed in Ubuntu.  This would
replace openbsd-inetd, and with this scheme would require a one-line
change to a single package.  Other CDDs might want to use other
inetds, e.g. xinetd, or a "null" inetd which does nothing.

For MTAs, other distributions might want to switch from exim4 to a
more lightweight MTA (or even a "null" MTA for minimal systems).  This
system would allow that to be simply and easily configured.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: pgpm6SDDgASEj.pgp
Description: PGP signature


Reply to: