Rationale
Currently local server virtual provides are used in fedora, the one I am aware is smtpdaemon for a mail server listening on the smtp port. webserver is also another potential candidate, but as seen below it doesn't seems to be used for a web server listening on the http port. Therefore the naming and the exact meaning of those virtual provides is not clear. There is no way to discover the name of such virtual provides, nor to list them all.
This draft proposes a naming scheme for virtual provides corresponding with local servers listening on a specific port, with a strict meaning of the provides and a naming scheme generic and rule based.
The aim is not to inflate the number of virtual provides, they should only be added if needed, but to provide a more systematic naming scheme.
Proposal
Virtual provides corresponding with local servers should be named along
server(port_name)
port_name being the service name associated with that port number in /etc/services, or the port number when no record exists in /etc/services (but in that case it is doubtful that a virtual provides is useful).
So, for example a virtual provides for a server listening on port 80 should be server(http).
Things to do if the proposal is accepted
collect the virtual server provides
Currently smtpdaemon. Don't hesitate to add more if you know them.
change the virtual provides
For the known existing virtual provides.
smtpdaemon should be changed to server(smtp).
# repoquery --whatprovides smtpdaemon sendmail-0:8.14.1-4.2.fc8.i386 postfix-2:2.4.5-2.fc8.i386 exim-0:4.68-1.fc8.i386 postfix-2:2.4.5-2.fc8.i386
It looks like all the packages that should provide this virtual provide are listed here.
# repoquery --whatrequires smtpdaemon mlmmj-0:1.2.15-1.fc8.i386 amavisd-new-0:2.5.2-2.fc8.noarch fetchmail-0:6.3.8-3.fc8.i386 bugzilla-0:3.0.2-0.fc8.noarch
I remember having inspected those packages and if I recall well, they really requires a local smtp server.
webserver status is less clear. Indeed there are packages that set up an http server that are not providing this virtual provide:
# repoquery --whatprovides webserver httpd-0:2.2.6-3.i386 httpd-0:2.2.6-3.i386 boa-0:0.94.14-0.8.rc21.fc8.i386
And it seems that none of the packages that requires webserver requires a local http server:
# repoquery --whatrequires webserver htdig-web-3:3.2.0b6-12.fc8.i386 namazu-cgi-0:2.0.17-2.fc8.i386 nut-cgi-0:2.2.0-3.fc8.i386 postgresql-pgpoolAdmin-0:1.0.0-7.fc8.noarch wordtrans-web-1:1.1-0.2.pre13.fc7.i386 bugzilla-0:3.0.2-0.fc8.noarch darcs-server-0:1.0.9-6.fc8.i386 webalizer-0:2.01_10-34.i386 phpMyAdmin-0:2.11.0-1.fc8.noarch nut-devel-0:2.2.0-3.fc8.i386 qdbm-cgi-0:1.8.75-3.fc8.2.i386
Instead most of them seem to require a cgi server, and some clearly requires the apache web server since they install their files in apache specific directories.
Therefore the semantics of the webserver virtual provides may be more along a web server providing cgi support (namazu-cgi, nut-cgi, darcs-server, qdbm-cgi) and therefore can stay. Sometimes it means a cgi server, but also also means a server with apache like web server configuration directory and config file (bugzilla, htdig-web, phpMyAdmin, postgresql-pgpoolAdmin, wordtrans-web) in that case the requires may better be httpd, but this is out of the scope of that proposal.
nut-devel seems to be a mistake (hopefully the merge review isn't still done).
Plan
A server(smtp) provides should be added to the packages providing smtpdaemon by F-9. The Requires for all Fedora packages should be changed to use the new provides by F-9, too. When you implement the new Provides, please leave the old ones so that third party packages that have grown to depend on them can continue to function, at least for F-9. After F-9 keeping or removing the provides is left to the packager.
PatriceDumas will fill bugs and provide patches for spec files as soon as (and if) FESCo ratifies this proposal.
There is a need for a server(xdmcp) in ltsp5, and for the corresponding virtual provides in gdm, kdm, xdm, wdm. PatriceDumas is also volunteering to take care of that.