Re: Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)
Steve Langasek wrote:
>> I'm reluctant to change the default behaviour of start-stop-daemon at this
>> point. What do other people think of making --oknodo the default behaviour
>> and adding a new option to force the current default behaviour (exit with
>> failure if nothing had to be done)?
>
> I think this sounds like there's no real transition plan between the two
> states; anything that actually relies on the current behavior of s-s-d
> without --oknodo will suddenly be broken. Changing the semantics of core
> tools in this way is a bad idea.
Here a proposal for a transition plan:
Before lenny, start-stop-daemon can gain a new option that:
- conflict with --oknodo (the new option can be called --no-oknodo for example)
- enforce the current behavior with start-stop-daemon
In sid, after lenny, start-stop-daemon can be changed to emit a warning if
invoked without --oknodo or --no-oknodo. Maintainers must update their scripts.
In lenny+1, (ie just before the release of lenny+1) start-stop-daemon revert
the previous patch (ie does not show warnings) so that upgrade from lenny
(maintainer script without --no-oknodo) to lenny+1 (maintainer scripts with
--no-oknodo or --oknodo) does not trigger lots of warnings.
In sid, after lenny+1, start-stop-daemon can fail if no option are given
(or change its behavior).
Another one is:
Before lenny, start-stop-daemon can gain a new option that:
- conflict with --oknodo (the new option can be called --no-oknodo for example)
- enforce the current behavior with start-stop-daemon
In sid, after lenny, lintian checks and warns if none of the two options
is given.
In both case, the goal is to ensure that the maintainer really choose the
behavior he wants for start-stop-daemon
> The right answer is that we should be fixing the wrong init scripts, not
> trying to coerce all the init scripts with a change in s-s-d semantics. An
> init script may have a legitimate reason to want to check for the
> difference between exit statuses 0 and 1, without necessarily using this
> information a way that breaks the init script's own exit status, and
> changing s-s-d behavior will break these legitimate use cases.
>
>> The alternative is to change policy and/or lintian to ensure that packages
>> are using --oknodo unless they have a good reason not to.
>
> This was already discussed on debian-devel in March of this year.
>
> http://lists.debian.org/debian-devel/2008/03/msg00772.html
>
> Feel free to propose an amendment to policy that clarifies that "sensible"
> behavior is equivalent to --oknodo (without implying that init scripts are
> required to use s-s-d!), and I will happily second it; as I already
> commented in that thread, I think this is a mere clarification of what the
> policy has always been, not a change to policy at all.
>
>>> [1] LSB specifications about init script actions:
>>> http://www.linux-foundation.org/spec/refspecs/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
>
> That one's starting to get up there right next to "our priorities are our
> users and free software" on my list of Facile Arguments That Demonstrate The
> Poster Has No Clue. :P
>
--
Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main
Reply to: