Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)

[Vincent Danjean-3]

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@...
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




--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Fri, 04 Jul 2008, Vincent Danjean wrote:

> 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:

THanks, I could come up with a transition plan myself if needed. But
compare your suggestions with: "someone goes over all init scripts, file
bugs and in lenny+1 we're done". (No this is not something I intend to
pursue, but anyone that cares could do and would probably be granted a
release goal for this)

The transition would be hugely complicated for little gains since most
script already do what's needed.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Marc Haber-3]

On Sat, Jul 05, 2008 at 10:58:35AM +0200, Raphael Hertzog wrote:
> THanks, I could come up with a transition plan myself if needed. But
> compare your suggestions with: "someone goes over all init scripts, file
> bugs and in lenny+1 we're done".

That'll cause tremendous pain for backporters. I'm opposed.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Vincent Danjean-3]

Marc Haber wrote:
> On Sat, Jul 05, 2008 at 10:58:35AM +0200, Raphael Hertzog wrote:
>> THanks, I could come up with a transition plan myself if needed. But
>> compare your suggestions with: "someone goes over all init scripts, file
>> bugs and in lenny+1 we're done".
>
> That'll cause tremendous pain for backporters. I'm opposed.

My main idea (with or without trasition plan) is to have an option (for
example --no-oknodo) in lenny allowing maintainer to tell he wants the
current behavior of start-stop-deamon.

Whether warning are generated or not, bugs filled or not, lintian complains
or not, default behavior changed or not, ... is not really important for my
point of view (and can be decided after lenny) *iff* the option already
exists in lenny (else, we will have to wait for lenny+1)

  Regards,
    Vincent
--
Vincent Danjean       GPG key ID 0x9D025E87         vdanjean@...
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




--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...