Finger daemons in Debian should use a virtual package
Hi good people,
There are all sorts of daemons for various services in Debian, and there are
services that have several daemons, and therefore several packages. To
enable smoother transitions from one daemon to another, we have instated
virtual packages which these packages can provide and conflict with.
Although there is a possibility to run some of these servers simultaneously,
by making them bind to different ports, it was agreed that the most common
use is on the default port, and that until a more flexible solution (such as
a debconf query) is created, packages will use this.
Examples are mail-transport-agent (port 25, SMTP service, packages exim,
masqmail, postfix, postfix-tls, sendmail, ssmtp, zmailer, zmailer-ssl),
ftp-server (port 21, FTP service, packages ftpd, proftpd, wu-ftpd) and
ident-server (port 113, IDENT/auth service, packages midentd, oidentd,
pidentd). Examples of a virtual package that packages provide but with which
they do _not_ conflict is httpd, and that's most probably because it's not
so uncommon to run several HTTP daemons on different ports (aside from 80).
Now, the current issue is that the same thing should be done for the
*fingerd packages. That's why I'm sending this to folks maintaining
{c,e,f,x,}fingerd packages. Currently these packages either conflict with
others, or use bits of update-inetd magic to set up its entry in
/etc/inetd.conf that is often FUBAR, and SNAFUs people's inetd.conf entries.
Since there's not much point in running a fingerd on a non-standard port (at
least I haven't seen done anywhere, or a finger program that can query
different ports), it would seem appropriate to make these packages provide
and conflicts with a virtual package called `finger-server', i.e. add this
to the control file:
Provides: finger-server
Conflicts: finger-server
The virtual package should be added to the official Policy list of virtual
packages, too.
I can (and will, if allowed) do as many NMUs as necessary to get this done.
Since it should be done in potato, too, I'm sending this to Richard to ask
can I/we upload changed packages in frozen. We have one full week to do it,
which should be enough (these packages aren't large in general, mostly about
15KB .debs, I think even the m68k build daemon can catch up with these in a
day or two :), and I don't think there is any chance that anything RC would
break because of those two changes in these packages.
How about it, then?
--
Digital Electronic Being Intended for Assassination and Nullification
Reply to: