Starting daemons after install not always what the user wants, but what/how to do ?
Some programs may be used as system daemons, but can also be used by a
user for some other purpose. For example, fetchmail can be used as a
system-wide mail fetcher, but can be used and configured by a user to
fetch his own mail, through his own setting.
Now, let's say someone creates some gnome-fetchmail program that would
take care of the configuration and the daemon starting/killing in sync
with gnome-session. This gnome-fetchmail package would indeed depend on
the fetchmail package.
IIRC, fetchmail asks the user if he wants to run fetchmail as a system
daemon when the fetchmail package is installed. Now, if the user wants
gnome-fetchmail, he will be asked that question, while actually, he
doesn't care at all. He just wants gnome-fetchmail, doesn't need
fetchmail as a system daemon, but doesn't necessarily have a clue what
he is supposed to choose for use with gnome-fetchmail.
If the fetchmail install script didn't ask the user, the maintainer
would have the choice between enabling it by default, or not enabling
it. For fetchmail the choice would probably be to not enable it, but for
some other services, probably to enable it.
And the problem is actually happening, it's not hypothetical.
There is gnome-user-share, that uses apache2 to set up a web dav share
on some random high port and make it available as a zeroconf service
through avahi. The package depends on apache2. Thus, when installing
gnome-user-share, while the user only wants to have the ability to share
his own files through a gnome interface, he also gets a full http server
running on port 80 of his computer, which he didn't really intend.
Expecting the user to disable apache by himself is not a solution.
Desktop users are not all that clueful.
I could have filed a bug to apache2, but it is more of a general issue
that needs a general solution, i think. A similar situation may already
exist with some other packages, actually.
Now, the big question is, what do you, fellow DDs, think would be a
solution for that problem of programs depending on other programs rather
than the service they provide.
Mike
Reply to: