On Thu, 2010-07-29 at 15:58 -0700, Russ Allbery wrote: > I think LSB exit codes are by far the most controversial part of the LSB > proposal, are of dubious utility, What are the arguments against them? > and would mean declaring most of Debian > init scripts currently buggy. That makes ever introducing such changes extremely difficult, even if the are worth it (as the dependency based booting proved ;) ) > I'm personally unconvinced that adopting the LSB exit code standard is > ever worth doing, but at the least, Policy is not the place to do it, > since it's not even close to existing practice in Debian. This is one of > those places where, if this is something that the project wants to do, it > should be done in the packages first and then documented in Policy once > that work is mostly done, similar to how the init script headers have been > handled. Fair argument. Is there a "mechanism" in Debian... e.g. something like a staging area, where one could specify such stuff (or things like the dependency based booting) in order to clearly tell everybody "this is the future,... start adopting it" but not making their packages immediately break the policy? I mean just by "this makes things better some day" it's hard to convince maintainers ;) > > 2) At least let initscripts allow to fail (when the package is removed), > > if there's strong reason for them (as e.g. in my dm-crypt example). > Do you have an example of a bug or user problem where the current Debian > Policy caused problems and would have been fixed by having a different > requirement? I suspect this is only a theoretical issue. No... see the example with cryptsetup I've described above, where following the policy would open a security problem. > > 3) Suggest to reconsider the above for initscripts. It's absolutely > > reasonable that left over configuration files shouldn't be allowed to > > break anything. But IMO it does not in the case of initscripts. You just > > get the warning message,.. but everything's fine. > > I'm personally strongly opposed to changing this design principle in > Debian. If the package is removed but not purged, the init script should > not report errors. This is a common case in Debian, and I think it would > be a significant regression to have init scripts start producing errors in > this situation. Well that was just a suggestion :) ... anyway... can you tell examples where this would really produce errors (I mean except some messages to that initscript foo has failed). > > Imagine a package using the status action from another facility to find > > whether it's running or not. > > > If it runs, it starts its own daemon with different options e.g. to make > > use of that daemon. > > That sounds like a rather dubious design. Do you have some specific case > in mind where you'd want to do such a thing? At this point it was rather theoretical thinking on what could happen,... but I have actually a case: My long term wish (and it will be a very very stony way) is to package dCache... this make use of different other daemons e.g. a database (postgresl, or others) and some message brokers (activeMQ, an internal system)... etc. Require-start or should-start is AFAIU not the solution to start them, because one wants to be able to select alternatives. And on needs to tell the actual deamon which is used. Therefore, testing with status could be a nice solution,... or at least I cannot think of any better right now ;) > > Now even if status is implemented,... the package of the initscript > > might be removed (!purged)... we get exit 0 then. The script believes > > the status would run. It does however not. > > I can see how this is a problem for status in particular, since status has > different exit code requirements than normal init script actions. The > current Policy requirement: > > These scripts should not fail obscurely when the configuration files > remain but the package has been removed, as configuration files remain > on the system after the package has been removed. > > is still reasonable, but the specific recommendation: > > Therefore, you should include a test statement at the top of the > script, like this: > > test -f program-executed-later-in-script || exit 0 > > doesn't really make sense for status; it only makes sense for the init > script actions currently documented in Policy. If we standardize the > status action, we should at the same time alter that advice to not > recommend an 0 exit status for the status action if the package is removed > but not purged. Which would probably be 5 then :D > Exiting with a non-zero status when the daemon isn't running isn't > "failing obscurely" and is fine under the current Policy requirement; it > just doesn't work with the Policy recommendation for how to implement that > requirement. Uhm... what exactly do you mean? :-O Best wishes, Chris. :)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature