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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
