On Wed, 15 Nov 2000, Anthony Towns wrote: > > I could leave the more verbosy stuff that fallbacks cause, but THAT would > > give quite a lot of room to user confusion. When someone starts the holy > > war against the amount of crap a upgrade sends to the screen, and AFTER the > > TeX and emacsen-related packages succumb to said holy war and stop spewing > > dozens of lines of unneeded info to the screen, I'll remove the slightly > > verbose fallback messages (which amount to 3 lines, I think) ;-) > > "Hey, everyone else is racist, why shouldn't I be too?" As I said, they're there to avoid confusing the user. If they had no possible purpose I'd have removed them before invoke-rc.d ever seen the light of this list :-) > Don't remove them, just make them conditional on a --verbose option. I would, but I want them there in the default case. The idea of fallbacks is not even remotely common (it's not difficult, but nobody else does it), so I think it is best to leave the messages there for a while. In a few years, they can go away. Without the restart-if-running fallback, invoke-rc.d simply says: invoke-rc.d: initscript action "restart" not executed. Which is what 99.99% of the Debian systems will ever generate. People using policy-rc.d will probably want the more informative messages "on" by default (policy-rc.d is the only thing that can generate fallbacks without the restart-if-running code). > > Now, please lets stop with the nonsense. > Please stop with the condecension then. Yeesh. Eh, sorry. I was starting to get annoyed, and your joke example didn't help. Wrong joke at the wrong time... > > > invoke-rc.d foo restart > > > for scripts that do support r-i-r, use: > > > invoke-rc.d foo restart-if-running > > This will only work if I add to the 'restart-if-running' policy proposal > > that: "should a service support restart-if-running, all _maintainer_ scripts > > that invoke initscript actions on that service *must* *never* use 'restart'. > > Erm, there's nothing fundamentally wrong with them using restart, > it'll just mean they don't get the benefit of having written a > "restart-if-running" option. By itself, there's nothing wrong with restart. However: * restart out-of-runlevel is now denied (does nothing) by invoke-rc.d. If a maintainer script wants to make sure a running daemon is stopped and restarted (which is why 90% of the maintainer scripts would use a restart), it MUST use either "stop; start" or "restart-if-running" instead of "restart", or else the service will not even be stopped. Also, given the fact that the only way a maintainer responsible by the service-providing package can signal he does NOT want his daemon running afoul out-of-runlevel is to add 'restart-if-running', 'restart' now has to be severely deprecated if 'restart-if-running' is added. OR, we can have invoke-rc.d fallback to 'restart-if-running' for a 'restart'. This have the same effects that the above has. There's no need to do both, but one of the two should be done. > And, uh, how many packages restart other packages services? Are there any > other than major libc6 upgrades? The common case here seems to be packages dict-* restarts the dictd service, for example. Others probably exist, it is actually a not-so-uncommon requirement, "data packages" for a daemon sometimes need to do it (when a force-reload isn't enough). But I don't have so many packages installed so as to do an exaustive search. > Look, all I'm saying is that having a bunch of error messages appear in > the usual case is a bad implementation choice, not that it's illegal or > against policy or whatever. I understood that. I was only pointing it out that many people think that such messages are acceptable, and that it will take some doing to change it in Debian. Since you seem to be bothered by them more than I am, you might want to do what it takes to stop them. > > > > Also, do remember that the fallback will only happen in a system > > > > where the local administrator knows enough about runlevels to change > > > > Debian's default of 'start service in all runlevels'. > > > It'll also happen if the admin changes to single user mode, and then > > > installs some packages. > > I could very easily lift the restriction on starting (and restarting -- it's > > the same thing) stuff in runlevel S (i.e. runlevel S is never > > 'out-of-runlevel' by default). > > Huh? No services should be started in single user mode. Services are for > runlevels 2 and 3. You can tell by ls -l'ing /etc/rcS.d or similar. It's > nothing special, except that in a default Debian install nothing's > started in it. Are we talking at complete cross purposes now? I'm lost. No services should be started by the initscript system (INIT + /etc/init.d/rc ) automatically in S unless they're meant for runlevel S, of course. Hmm... I was hasty. Let me rephrase the problem: You're in single user mode. You install/upgrade a package. Do you want its services started or not (currently they're NOT started unless they're runlevel S stuff)? A few minutes of thought in the issue tells me that I should leave things as is (i.e.: do not start stuff in runlevel S unless they're meant for runlevel S). It seems that you agree with me. > > Consider the proposal split. I'll follow up with a new policy proposal for > > 'restart-if-running'. > > Okay, consider this a second for invoke-rc.d then. It's a long overdue > addition. Thank you. I'll send a changelog and new policy diff in a few minutes (I need to edit invoke-rc.d before -- I want to fix an implementation shortcoming, and don't worry: it just allows policy-rc.d to override the deny rules for start and restart out-of-runlevel with something else, should the user want it to). Please review the changelog and new policy diff and second them when they arrive in the BTS (just to make sure it doesn't look like you seconded something and then I changed it under your foot). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Attachment:
pgpyXT0YLHtO1.pgp
Description: PGP signature