This one time, at band camp, Frans Pop said: > Patrick Schoenfeld wrote: > > * RUN_NEW_SERVICES_AFTER_INSTALL=<yes|no|1|0|true|false> > > I dislike the semantics of this because it does not allow for the case > where for whatever reason (e.g. new system install) you have to reboot > shortly after installing a package before you had a chance to > review/change the configuration. > > IMO if an admin chooses not to "start after installation", the service > should also not be started after reboot before the admin has acked > things. So I'd prefer an implementation that uses NOT_CONFIGURED instead > of what you're proposing. > > An alternative could be a mechanism that checks some flag > "HAS_BEEN_STARTED_BEFORE" (either automatically or manually), but that > could cause problems later in the lifetime of the system, e.g. when a > system is restored from backup and those flags are not included (because > they are too obscure and have been overlooked). It feels to me like we're all kind of ignoring the current mechanism for enabling and disabling services that we already have. It might be useful in this conversation to seperate out two different ideas: It would be nice to have a consistent user interface for enabling and disabling whether a given service starts at boot (something like redhat's chkconfig, but possibly one that works with init script dependencies). It would be nice for packages to be able to opt in to a common system for allowing an admin to decide if new packages will be enabled with the above (or similar) system. I think it's probably a mistake to make all packages do this by default - hal and dbus being installed as dependencies are good examples of this behavior breaking normal expectations, but things like avahi-daemon being installed by cups is a good case for having things not started by default. This common system can be as simple a thing as ACTUALLY_RUN=1, which only controls maintainer scripts calls to the mechanism that updates symlinks and then calls invoke-rc.d. This should not be referenced in init scripts themselves, so that admins can run the scripts manually or have normal behavior from the init script when it's symlinked appropriately. Just my 2p, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature