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

Re: Policy regarding virtual packages

Roger Leigh <rleigh@whinlatter.ukfsn.org> writes:

> 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.

Was there any further discussion needed about this?

The only objection I saw was to the package naming, which I would like
to hear alternatives for (currently $virtualname-default).  I also got
one mail privately concerned that packages should still be able to
specify a particular preference should they need it; it is of course
possible to have a "preference | virtual-default" dependency.

Unless there are any valid objections, I would like to implement the
above inetd-default packages for etch.  This would require mass-filing
bugs against about 200 packages; they were listed in an earlier inetd
thread.  This would switch their current openbsd-inetd/netbase
dependencies to using inetd-default.

Implementing it for all other virtual packages would also be nice
(particularly m-t-a), but does need approval first.

Any further comments?


  .''`.  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: pgpAtuMsAcMT5.pgp
Description: PGP signature

Reply to: