Ahoy Petter! On Tue, Aug 18, 2009 at 04:37:45PM +0200, Petter Reinholdtsen wrote: > With dependency based boot sequencing, I discovered what I believe is > a bug in the init.d script. The provides should be unique and > preferably the name of the script. The current one conflict with the > console-screen script in the console-tools package. The $local_fs > dependency is redundant as $remote_fs implies $local_fs. To make sure > the ordering of console-screen.kbd.sh, console-screen.sh and > console-setup is well defined when all these packages are installed, I > suggest stating that console-screen should run after > console-screen.kbd. And to avoid surprises, I list all scripts > currently depending on console-screen in the archive as script that > should run after console-screen.kbd.sh. This will make sure these > scripts are started in this order if all three packages are installed: > console-screen.kbd, console-screen.sh, console-setup.
Thank you for your report.
console-tools (which contains console-screen.sh) and kbd
(console-screen.kbd.sh) conflict, so they can never be installed at the
same time. console-screen.sh won’t do anything if the “consolechars”
binary isn’t present, the same thing goes for console-screen.kbd.sh and
“setfont”. The problem you describe only occurs when a user replaces
one console utility package by the other, and the old package isn’t
purged in this process. Both scripts do pretty much the same thing, and
they are mutually exclusive, so only one of them will ever be executed
during init. I’m still very much in favour of something like an
X-If-Exists header, so console-screen.kbd.sh can state
# Provides: console-screen
# X-If-Present: /bin/loadkeys
whereas console-screen.sh has
# Provides: console-screen
# X-If-Present: /usr/bin/consolechars
The insserv of my dreams would just ignore a script completely if the
file asked for isn’t there. This way init scripts of conflicting
packages can coexist peacefully even if conffiles are left over after
removal. I actually tried to come up with a patch to inssevr ages ago,
but remember failing early on because I didn’t have time to get behind
insserv’s inner workings. Do you think such a mechanism is a good idea
(and its implementation feasible) at all? Maybe there are some dangers
or serious problems I miss completely.
> I notice this issue was discussed in #483607. I believe the
> X-Start-Before: header in this patch solve the problems raised there,
> after checking all init.d scripts in the archive.
I don’t like this approach because of its fragility. As far as I can
see, even your patch appears to miss console-cyrillic (where
console-screen is only a Should-Start, but the package depends on kbd |
console-tools, and one of console-screen.sh and console-screen.kbd.sh is
always needed). And then I don’t like the idea of adding more and more
“reverse dependencies” to the X-Start-Before: line as I grep the whole
archive from time to time, or users report bugs. In my eyes, this way
seems to defeat the purpose of the LSB init script headers altogether.
> Another approach would be to decide on a new virtual facility name to
> use for this kind of service (like $syslog).
Yup, I thought about that and may in fact take this path eventually.
There are only few packages that would have to be changed from
console-screen to (say) $console requirements. I nonetheless think it
isn’t really nice to create a new virtual facility for two init scripts
of which one won’t even run if the other one does.
Cheers!
--
Michael Schutte <mi...@uiae.at>
signature.asc
Description: Digital signature
