Hi, why two packages? A little bit of magic should do it: Service gets installed turned off, and whatever the administrator sets is respected - on upgrade, on logrotate, on boot. This would require some clarifications (is update-rc.d now for administrators or for package maintainers) and some common guidelines (some packages currently use /etc/defaults/something, some use the symlinks in /etc/rc?.d directly, others have something set in /etc/init.d/something or use some magic, like checking for a line in /etc/inetd.conf). Ideally, all network daemons, from the administrator POV: * are installed disabled * may be started temporarily (/etc/init.d/package start) - then being logrotated, restarted on upgrade, but no start on boot * may be started permanently (perhaps symlinking in /etc/rc?.d) - logrotated, restarted on upgrade, restarted on boot * may then be temporarily disabled (/etc/init.d/package stop) - no logrotate restart, no start on upgrade, but start on boot. That is, for each service we have two states ( (not)running generally and (not)running right now) which should both be off on installation and never be changed by upgrades or cronjobs. [For correctness sake: since on boot the "right now" state is undefined, starting the service according to the "generally" state is compliant with these rules]. Questions to be solved: how to implement, what interface for package maintainers, what interface for administrators nomeata Am Di, den 30.03.2004 schrieb Zefram um 16:08: > Patrice Fortier wrote: > >I had updates for ssh, portmap and nfs-common last week, and > >each update restarted its service even if I had disabled them > >(update-rc.d -f xxx remove). > ... > > All of this rather resembles Bug#176009 (cron script starts a stopped lpd) > which I submitted over a year ago (just adding to the list of gripes in > this thread). We clearly have a general problem with network daemons, > not just a problem with a few specific ones. > > Therefore, I suggest that we separate each of these daemon packages into > two, one that provides the daemon software and a separate one to run it. > That way those of us who want to install a daemon and use it in our own > way would not be hampered by someone's idea of how the daemon should > normally be run. And where the daemon is packaged with a client, > installing the client wouldn't cause an unwanted daemon to run. > > Example: the "ssh" package would, as now, provide both the ssh client > and ssh server, but wouldn't contain an init script. There would be a > separate "ssh-daemon" package, with a dependency on the "ssh" package, > and containing an init script. > > Debian should ship with *no* network daemons listening by default. > I'm rather surprised that it hasn't adopted this policy already. -- Joachim "nomeata" Breitner nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: joachimbreitner@amessage.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil