On Fri, Jan 21, 2005 at 12:09:42PM +0800, Dan Jacobson wrote:
> Sure, one can go behind the backs of maintainers with
> > http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.6
> > ("Disabling daemon services")
> and hope you remember what you did. But it's not as friendly as
> the approaches more and more packages are taking, as seen in my /var/log/boot:
> SpamAssassin Mail Filter Daemon: disabled, see /etc/default/spamassassin
> hylafax is disabled, see /etc/default/hylafax
> OpenBSD Secure Shell server not in use (/etc/ssh/sshd_not_to_be_run)
> Not starting xprint: disabled in /etc/default/xprint
> Not starting apache2 - edit /etc/default/apache2 and change NO_START to be 0.
> We are still waiting for
> 281974 cupsys: allow not starting on boot
> 218040 fetchmail: no way to not start on boot permanently
> Now that maintainers realized that one might like a package installed,
> but perhaps only plans to use it unoften, it only makes sense for not
> starting at boot to be offered as a friendly configuration option,
> instead of needing some devious guerilla techniques to thwart the
> packages starting.
> Sure those tactics might work, but whatever you did isn't easy to see
> as it is in /etc/default/.
> That each package will have its own way of not starting in
> /etc/default/ is because of disbelief that there needs a standard
> mechanism to do this _that the user can encounter with
> dpkg-reconfigure_, with the results stored in /etc/default/ etc. No
> more monkeying with the links behind maintainers' backs, etc. Proof
> that something visible upon dpkg-reconfigure is better is seen in the
> more and more packages that are getting on the user friendly
> bandwagon.
This is not "monkeying with the links behind maintainers' backs", this is
the *documented interface* for changing which daemons run in which
runlevels. Asking individual maintainers to reinvent the same per-package
solution for opting not to start a service in the default runlevel is
wasteful and ill-designed. We need a central, user-friendly interface for
managing start script policies, not to pick off 100 different packages
one-by-one until they're all trying to duplicate the same code with
different bugs each time.
I hope that at least the cupsys maintainer will close this bug without
mangling the package in this fashion; there's no reason to have the cupsys
server package installed if you're not going to use it as a server. If you
can't be bothered to move a symlink so that you only have to start cupsys
"once a year" when you're printing, then FFS, surely you can at least remove
the package using the package management interface and only install it when
you need it. That's bound to save you disk space on keeping an unpacked
copy around, as well as bandwidth for security updates you wouldn't need.
The xprt-xprintorg at least has the additional factor of being a dependency
of other packages (x-window-system), so there's pressure from users to be
able to install it without enabling it; but even then, the default
configuration of Xprt does not allow network connections, so I really don't
see the point of complicating the package for the convenience of users who
*refuse* to run "rm /etc/rc2.d/S20<package>" when indicated to do so.
--
Steve Langasek
postmodern programmer
Attachment:
signature.asc
Description: Digital signature