RE: Bug#317892: ITP: bum -- tool to manage boot scripts
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 S20scriptname symlink in directories related to runlevel 2,3,4 and 5 and will remove any Kxxscriptname symlink in the same directories. Further it creates K20scriptname 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 Sxxscriptname symlink. Very nice program, but the behavior described here is incorrect. In order to deactivate the service, bum should install a Kxxscriptname 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 S20scriptname symlink in directories related to runlevel 2,3,4 and 5 and will remove any Kxxscriptname symlink in the same directories. Further it creates K20scriptname 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 Sxxscriptname symlink. Very nice program, but the behavior described here is incorrect. In order to deactivate the service, bum should install a Kxxscriptname 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
