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

This is Interesting: Free IT Magazines  
Home > Archive > Debian Developers > July 2005 > Bug#317892: ITP: bum -- tool to manage boot scripts





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Bug#317892: ITP: bum -- tool to manage boot scripts
Federico Di Gregorio

2005-07-12, 7:56 am

Package: wnpp
Severity: wishlist
Owner: Federico Di Gregorio <fog@initd.org>

* Package name : bum
Version : 1.3.0
Upstream Author : Fabio Marzocca <thesaltydog@gmail.com>
* URL : http://www.marzocca.net/linux/bum.html
* License : GPL
Description : tool to manage boot scripts

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.


--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Thomas Hood

2005-07-12, 7:56 am

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.

Wishlist item: Grep the postinst files in order to obtain the
"factory default" sequence numbers and implement a "restore
factory default sequence numbers" feature. See my last comment
in #183460.
--
Thomas Hood




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Humberto Massa Guimarães

2005-07-12, 5:57 pm

> On Tue, 12 Jul 2005 11:15:42 +0200, Federico Di Gregorio wrote:
>
> Consulting the documentation...
>
> 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Thomas Hood

2005-07-15, 6:06 pm

On Tue, 12 Jul 2005 11:09:56 -0300, Humberto Massa Guimarães wrote:
> 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...


Currently it does both. I think that it should just Depend on
sysv-rc and leave the Conflicting up to the latter.

The salty dog and I have been discussing runlevel editors in
general and bum in particular. I think that the next release
of bum will be rather good.

--
Thomas Hood


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com