[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Bug#317892: ITP: bum -- tool to manage boot scripts



> On Tue, 12 Jul 2005 11:15:42 +0200, Federico Di Gregorio wrote:
> > Boot-Up Manager is a graphical tool to allow easy configuration
> > of init services in user and system runlevels, as far as changing
> > Start/Stop services priority.
> 
> Consulting the documentation...
> > 1.  Activate a de-activated script.
> > BUM will create a standard S20<scriptname> symlink in directories
> > related to runlevel 2,3,4 and 5 and will remove any
> > Kxx<scriptname> symlink in the same directories. Further it
> > creates K20<scriptname> in runlevel 0,1 and 6 directories. It
> > also checks that the script "executable" and, if needed, will
> > change it so that it is.
> >
> > 2. Deactivate an activated script.
> > BUM will remove any Sxx<scriptname> symlink.
> >
> 
> Very nice program, but the behavior described here is incorrect.
> In order to deactivate the service, bum should install a
> Kxx<scriptname> symlink.  Testing confirms that bum fails to do
> this.
> 
> Without a K symlink in the directory for the current runlevel,
> when the service's package is upgraded, the service will be
> started in the postinst even though it is configured to be
> deactivated.
> 
> This issue has been discussed before and I believe that there is
> a good consensus about it now.  Bum's current behavior leaves
> deactivated services in a floating state and Debian does not
> at present correctly support services left in the floating state.
> (See #243159.)
> 
> You will need to choose an appropriate sequence number for the
> K symlink.  I suggest: If there is a K symlink in another
> directory then use its sequence number; otherwise use an old K
> sequence number stored in database; otherwise use 100 minus
> the S sequence number.  You may want to look at the source code
> of sysv-rc-conf too.  Among the runlevel editors currently in
> Debian it sucks the least.

I am a fan of vi + file-rc myself, but... anyway, the packager should conflict this package with file-rc or depend on sysv-rc, whatever is better...

HTH,
Massa



Reply to: