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? Thanks, 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:
pgpAtuMsAcMT5.pgp
Description: PGP signature