On Thu, 16 Nov 2000, Anthony Towns wrote: > Despite how it may appear, I'm not doing this merely to be obnoxious. :( Ok, don't worry. > On Wed, Nov 15, 2000 at 09:13:10AM -0200, Henrique M Holschuh wrote: > > 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 :-) > > I guess I'm not seeing what's confusing about it. If invoke-rc.d is meant > to fallback to restart-if-running, that's what the user should expect > when invoke-rc.d is called. If they're doing `apt-get install portmap', > it seems reasonable for them to (a) expect portmap to be restarted, and > (b) not to really care exactly how that happens. Well, I don't expect users to read the docs (oh, I *do* bitch at people for not doing it, and I myself try to make sure I did read all possible docs before asking something but...). Anyway, the whole fallback thing is not something I expect users to even know about for a while, and I don't want the error message from the initscript to show there alone (some initscripts won't even identify themselves in the error message, I think). I can reduce it to one invoke-rc.d: line only for all not-weird-as-hell cases, though. Would a single line invoke-rc.d warning before it attempts to do something involving fallbacks do? > > > 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 > > Maybe there's a reason nobody else does it :) Well, it's like shooting at a fly with a cannon if you just want to fix the bugs invoke-rc.d fixes. But I am aiming that cannon at the cruiser over there, and shooting it while the fly is in the path of the missile :-) invoke-rc.d implements something rather useful for some people in that whole policy stuff, and fixes some annoying bugs while at that (even if I _did_ code the entire thing because I got annoyed at said bugs once too often). > > Without the restart-if-running fallback, invoke-rc.d simply says: > > invoke-rc.d: initscript action "restart" not executed. > > I don't think it should even say that. (Well, unless someone's using > --verbose) Well, what about this: I can make it keep quiet if it should return a zero status code (i.e. fail silently since the script that called it doesn't want to bother with the action suceededing or not) -- do notice this is will be the standard behaviour -- and output the error message if --disclose-deny is used? This way, 'deny' fallbacks would be silent unless the script calling invoke-rc.d uses --disclose-deny. I may add a --verbose option yet, but we're discussing the default 'verbosity' level. Just making sure that's clear. > I don't have a problem with the concept of falling back to > `restart-if-running', I just don't like the way it invokes undefined > behaviour in existing scripts in (relatively) normal use. That's why I took 'restart-if-running' out from invoke-rc.d when I split the proposals: if 'restart-if-running' is not in policy, it is undefined. However, initscripts (of the sort that get registered through update-rc.d) are *not* supposed to go doing weird things if given something else than start, stop, restart and force-reload. They're to abort with a non-zero status and print an error message (and all update-rc.d-registered initscripts in my system will behave just like that, I checked). I'll make sure the policy proposal for 'restart-if-running' forbids an initscript (that's going to be registered by update-rc.d) to do anything but what the policy defines for the start, stop, restart, restart-if-running, reload and force-reload actions. And make it mandatory to abort with an error-status if the script receives an unknown action. There are very few scripts that violate the above, and they're all rcS.d-only and are trivial to fix (I'll fix them and email the diffs to the BTS before the restart-if-running deployment if it is approved). These scripts are never called by any maintainer scripts, though, so there's no risk of invoke-rc.d ever trying to fallback them. > > * restart out-of-runlevel is now denied (does nothing) by invoke-rc.d. [...] > > It's a bug, sure, but I don't think it's one we really need to stress over > (ie, "should" and normal severity seem quite enough). Especially since the Ok, I can leave with a "should". So you'd rather I toss this into 'restart-if-running' as a 'should', instead of the fallback using *one* (and only one) line for the error message? > update-rc.d all the time; and why people bitch about tex and emacs > upgrades (well, one of the reasons...). Heh :-) > > 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). > > Pfft. I may disagree with you how to do it, but I don't think you're > dishonest or anything. Oy, that's not what I meant. Just forget what I wrote above, we have better stuff to argue about :-) -- "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:
pgpXGUWVDh2gQ.pgp
Description: PGP signature