Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Geert Stappers]

Cntrl: retitle -1 Please clarify that sysvinit support decision depends on 
available sysvinit resources
Writing "Control:" without 'o' was on purpose.

On Sun, 28 Aug 2016 16:03:48 +0200,  Odyx wrote:

}... many wise words in an overheated thread ...

> It's not OKay for maintainers to preemptively remove working sysvinit 
> support. 

There can and should agree on.

It will imply there will be packages with bugreports on sysvinit breakage.

Having a 90% working sysvinit script is better then none.



> But I wouldn't like the TC to say "sysvinit is here forever",
> because I think  that's simply not true.

TC is smart enough to known that.


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Didier 'OdyX' Raboud]

Le vendredi, 26 août 2016, 12.55:56 h CEST Ian Jackson a écrit :
> There has recently been a thread on debian-devel ("Is missing
> SysV-init support a bug?) about the decision by a package maintainer
> to drop sysvinit support from their package.  The maintainer has said
> they are reconsidering, which is good.

Yes. There was a discussion, some arguments both ways, and a extensive 
blogpost [0] from the maintainer, where they write:

> Conclusions: yes, I will probably reintroduce sysvinit files just to avoid
> any flamewar.

For the case at hand, my reading of the events is that:
* the maintainer removed sysvinit support
* someone asked the wider community (d-devel) whether "missing SysV-init 
support (is) a bug?"
* the discussion on the list sparkled, and clarified the various subquestions 
(more below)
* the maintainer got convinced to revert his sysvinit support removal (maybe 
for the wrong reasons; but still)

The subquestions, as I see them:

A) is it currently acceptable to remove existing sysvinit support?
A.1) … even in absence of bugs in said support?
A.2) … with bugs filed, and help/patches provided ?
A.3.) … with bugs filed, help requested, but no patches?
B) is it currently acceptable to ship a new without package without sysvinit 
support?

In my reading, the answers given by the discussion for the various A questions 
are _no_ for A.1 and A.2.

For A.3, I think Sam summarized it well enough:
> However if someone is having difficulty maintaining the scripts or they
> are broken, it is reasonable for them to ask for help, and if no one
> steps forward, eventually the scripts will become buggy enough that the
> normal severity bug of a package without an init script is better than
> the state of a package with a broken init script

… that is: _it could be OK_.

The current answer to B), as per our (outdated) Policy is _no_. I feel there 
is wide agreement that this should be fixed though.

Ian Jackson wrote:
> But, the discussion on -devel has shown that there are some other
> maintainers who are considering similar steps, and that the project's
> view on this is not settle.

Having this discussion within the project is fine, and I'll need to be 
convinced that having the TC emit preemptive opinions on this subject will be 
doing more good than harm.

> So: would the TC please clarify that the decision that
> 
> For the record, the TC expects maintainers to continue to support
> the multiple available init systems in Debian.  That includes
> merging reasonable contributions, and not reverting existing
> support without a compelling reason.
> 
> still stands.

It does, I don't see a need to re-state that it does [1].

> and that the answer to this queston
> 
>However, that was two years ago. How long should we be expected to
>continue maintaining sysvinit scripts?
> 
> is "indefinitely, and specifically until a contrary decision by the
> TC" (subject to quibbles over the exact meaning of "maintaining").

For the record, I don't particularily appreciate the TC being told _what_ to 
rule (but I am a non-native-english-speaker, probably misinterpreting your 
"would the TC clarify that (…) the answer to this question (…) is (…)").

Furthermore, I (currently) disagree that your proposed answer is a good answer 
for the TC to provide to this question. In particular, it would put the TC in 
the position of needing to decide of the appropriate timing for phasing 
sysvinit support out. (And an MIA TC would default to "indefinitely", by 
construction).

This is something I see the Debian developer community figuring out by itself. 
The TC will always be available for escalations, as usual; I don't think we're 
at an escalation point where preemptively locking the discussion is useful.

> Or to put it another way:
>   The answer to "is missing sysvinit support a bug" is "yes, and
>   it will continue to be regarded as a bug until further notice".

I disagree, see my interpretations of the answers to the A{1,2,3} questions 
above.

>   Of course a maintainer is not required to personally fix every bug,
>   but a maintainer should not introduce bugs without good reasons, and
>   should merge reasonable bugfix contributions.

Yes. This shouldn't need repeating, obviously. Whether "removing untested, not 
updated and likely buggy sysvinit support" really consists of "introducing 
bugs" should be debated per-package though.

Le vendredi, 26 août 2016, 14.14:25 h CEST Ian Jackson a écrit :
> I think what is really needed is a clear statement from the TC that
> support for sysvinit should not be regarded as transitional or
> time-limited.

That's obviously the crux of the issue. I certainly see the sysvinit support 
as transitional and time-limited; Debian just hasn't decided for the shape of 
the transition period or its timespan.

It's not OKay for maintainers to preemptively remove working sysvinit support. 
But I wouldn't like the TC to say "sysvinit is here forever", because I 

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Bart Schouten]

Christian Seiler schreef op 28-08-2016 10:07:


... warehouse of troubles that need a million hours of employment
each year to keep it going ...
- you will hate the day when you discover you've been scammed ...


Or, when other people constantly and irrationally bring up
libsystemd0 again and again (see the current debian-devel thread),
then sorry, these kinds of comments make me lose any motivation in
still working on helping people out with sysvinit. It's becoming
more and more appealing to me to just say "screw sysvinit users",
I don't care anymore. I'm not there yet, but I suspect that I'm not
the only one who feels that way, so please, continue with this kind
of rhetoric, and see where you'll be at in a few years.


Actually that is not such a bad thing; I find that if the motivation 
doesn't come natural, then there is a good reason to stop doing it; and 
just doing it because people please you or it pleases people, is not a 
very good reason after all either.


I know the language is exaggerated but it is not actually all that 
inaccurate.


I simply do not trust people who make a livelihood out of having 
problems, that's all.


I do not trust policemen to solve crime, psychiatrists to cure mental 
illness, teachers to make people independent, governments to liberate 
people and systemd people to have you have a problem-free existence in 
your system ;-).


I am sorry but seeing that most everyone who works on Linux works for 
one big company, and more problems means more employment, and maybe that 
is a rad and unfair way to say it, or to say it here, where such people 
may not be the most people in charge.


And I like SystemD's model, and there is a reason I am using it and it 
took me at least a year for me to get to the point where I could write 
my own service files or knew enough about it to start hacking the system 
(only the init system).


It's not just Linux, or not at all Linux, but the world is comprised of 
people who make a living by having problems, and more problems is more 
money.


And sometimes I feel as though Linux is the way of taking something 
simple and creating a difficult solution for it, and then the rest of 
your days you are dealing with the difficult solution instead of with 
the simple problem.





No, sorry, that's simply patently untrue. There are some good init
scripts out there, but the vast majority of them are just plain
horrible. They kind of work, but they make a lot of assumptions
that break in a lot of corner cases. And writing good init scripts
is _really_ hard, because shell programming is awful. (Useful, but
awful.)


Alright, corrected.

But "High Availability" tells to me something that would need more 
advanced systems to control it. I'm not saying SystemD is all bad, not 
at all.


It is clear that SysV is rudimentary and broken but it was that way for 
a long time. But the power is that you can write your own scripts and it 
just doesn't take all that long to find out how to do something or 
effect a change since you can just read the code and it is just regular 
Bash code mostly.


What I mean is that I am not an avid opponent of Bash scripting and I 
quite enjoy it. What I mean is that I am an avid proponent of it ;-). 
And so for me something being just "script" is a powerhouse. I don't 
need to acquaint myself with the workings and peculiarities of some init 
system before I can affect it. They are generic skills. I mean that I 
prefer to have rudimentary, simple, scriptful skills that are as basic 
as they can possibly get because basic skills are better building blocks 
for larger things, than bigger things and more advanced skills.


I mean that if you keep things simple and elementary, you create a more 
powerful house, and this has long since been the philosophy of the Unix 
world.


I mean that for me it is a personal thing perhaps that I can much easier 
work with stuff that requires just programming skills of some sort, 
rather than acquaintance and knowledge of a particular system. I mean 
that I can work better with that because I already have the skills and I 
do not need to acquire them.




So yeah, for me sysvinit scripts are definitely no fallback. From
personal experience I am by _far_ more confident in maintainers
getting systemd services right than in them getting init scripts
right. (Obviously that doesn't mean that people don't get service
files wrong - of course that also happens from time to time.)


I know SysV is rudimentary and not very advanced.

It's just that to me it is that candle that will still work when the 
electricity goes down ;-).


*Shrugs*.

Sorry for the language here at times, I know I exaggerate. The 
exaggerating stuff is often easier to say than the non-exaggerated 
stuff. Apologies.


Bart.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Christian Seiler]

On 08/28/2016 08:37 AM, Bart Schouten wrote:
> Sam Hartman schreef op 28-08-2016 1:37:
>> Similarly, if the community of people who care about sysvinit  is 
>> unwilling to spend the time keeping it working, eventually sysvinit
>> as a whole will be unmaintained and buggy.
> 
> True, but I don't think those conditions are there.

Not yet, but a lot of sysvinit-related stuff still hasn't been
adopted after being orphaned.

> I mean that the statements:
> 
> a) the scripts need (urgent) maintaining
> 
> and
> 
> b) in the context of the actual maintaining they do need, the help 
> that is necessary isn't there.
> 
> Are not true.

I would agree that in this specific case, a) is not true (there's
no apparent problem with them that wasn't already there in Wheezy),
but I'm honestly not at all sure about b).

To bring out my pet example: with sysvinit systems, in Jessie it's
not possible to have /usr on NFS anymore. The reason is that mount.nfs
is now linked against a library in /usr. I reported the bug [1] before
the release of Jessie (and I only found it because I was testing stuff
with sysvinit, I don't use it regularly at all). But nothing happened.
Then when the whole monster /usr-merge thread happened on debian-devel
half a year ago, I brought up that bug again, and nobody seemed to
care either.

With systemd this bug doesn't occur, because on systemd systems the
/usr partition is mounted in the initrd - so you can indeed boot
/usr on nfs with Jessie - but only with systemd.

To be fair: the mounting of /usr in initramfs now happens regardless
of init system also in Stretch, so the bug will now only appear if
you don't use an initramfs. But it was not sysvinit people who made
that work, but Ben Hutchings who NMU'd initscripts. [2]

Actually, the only people who appear to be improving sysvinit support
in Debian at the moment appear to be systemd users. And the only
thing I hear from sysvinit users are complaints.

> I think the "maintainership requirement" of those scripts are 
> currently being exaggerated,

In this specific case? Probably. When the thread that started this TC
bug popped up on debian-devel, I was on your side: those scripts
shouldn't have been removed.

Heck, I even wrote init scripts for something I packaged recently.
(Admittedly, that was a simple daemon and the init script is trivial,
see [3].)

However, I've been working on something for the last couple of months
(on and off) to write some code to make stuff work on sysvinit for
one package I maintain, which I wouldn't need to do if I just wanted
to support systemd. Currently there's a huge workaround in the package
that is awful in every regard. And I really want to get rid of the
workaround, because it is detrimental to users in other ways (and the
workaround also affects systemd users), and do it properly.

But when I read stuff such as this: 

> ... warehouse of troubles that need a million hours of employment 
> each year to keep it going ...
> - you will hate the day when you discover you've been scammed ...

Or, when other people constantly and irrationally bring up
libsystemd0 again and again (see the current debian-devel thread),
then sorry, these kinds of comments make me lose any motivation in
still working on helping people out with sysvinit. It's becoming
more and more appealing to me to just say "screw sysvinit users",
I don't care anymore. I'm not there yet, but I suspect that I'm not
the only one who feels that way, so please, continue with this kind
of rhetoric, and see where you'll be at in a few years.

> Anyone writing an actual SysV init script would have thought of those
> things. That person would have felt responsible for it, because no
> one else would do it for you. That person would have built more
> intelligence into the startup script.

No, sorry, that's simply patently untrue. There are some good init
scripts out there, but the vast majority of them are just plain
horrible. They kind of work, but they make a lot of assumptions
that break in a lot of corner cases. And writing good init scripts
is _really_ hard, because shell programming is awful. (Useful, but
awful.)

Heck, even the skeleton Debian init script is completely useless
for use in a Pacemaker/HA environment - because start/stop will
_always_ return exit code 0, regardless of whether it worked or
not. (Only status returns different exit codes.) With sysvinit I
have _always_ had to patch init scripts to return proper error
codes when I wanted to use them in a HA environment. (And I've
done that since Squeeze, where there was no systemd.) This
violates LSB btw. (No, I didn't file a bug against the initscripts
package, let alone an MBF against all daemons with this problems,
not even before systemd was even a thing during Squeeze times,
because it was already very clear to me from just looking at the
bug list that nobody seemed to care about maintaining the package
properly, and I'd just be wasting my time.)

So yeah, for me sysvinit scripts are 

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Tollef Fog Heen]

]] Bart Schouten 

> > I agree on this too.  To the extent it should be considered
> > time-limited, it should be «until N releases after sysvinit is
> > removed» or somesuch, if that happens.
> 
> In legal terms, in law, it would be considered that the burden of
> proof lies with those who want to remove it.

As Sam writes, this isn't law and so this isn't terribly relevant.  We
routinely remove support for no-longer-supported infrastructure.

For a very similar situation, there was no disagreement about removing
upstart jobs once stretch is out.  (IIRC on the timing.)  Similarly, if
sysvinit is removed and we don't have other bits of the distribution
needing sysvinit scripts, we should stop shipping them.  This isn't true
today, so we're not going to remove sysvinit scripts.

> The burden of proof would be laid with the ones who want to remove it.

There's a balance that needs to be struck here: the needs of those who
need those scripts against the cost of maintaining them.

> I think any kind of time-limited removal that you pronounce in
> advance, is irrational.

I did not do this, though.

> "My grandmother used that" is not a good reason.

Good thing nobody used that as an argument, then.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Sam Hartman]

> "Bart" == Bart Schouten  writes:

>> I agree on this too.  To the extent it should be considered
>> time-limited, it should be «until N releases after sysvinit is
>> removed» or somesuch, if that happens.

Bart> In legal terms, in law, it would be considered that the burden
Bart> of proof lies with those who want to remove it.

Bart> Asking the supporters of those scripts to prove that they
Bart> still need them would be considered an unreasonable burden.

I'm nervous of going too far down the path of legalisms.

Asking those who need the scripts to prove (or even say) they still need
them is not what we want.

However if someone is having difficulty maintaining the scripts or they
are broken, it is reasonable for them to ask for help, and if no one
steps forward, eventually the scripts will become buggy enough that the
normal severity bug of a package without an init script is better than
the state of a package with a broken init script.

Similarly, if the community of people who care about sysvinit  is
unwilling to spend the time keeping it working, eventually sysvinit as a
whole will be unmaintained and buggy.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Bart Schouten]

I agree on this too.  To the extent it should be considered
time-limited, it should be «until N releases after sysvinit is removed»
or somesuch, if that happens.


In legal terms, in law, it would be considered that the burden of proof 
lies with those who want to remove it.


Asking the supporters of those scripts to prove that they still need 
them would be considered an unreasonable burden.


The burden of proof would be laid with the ones who want to remove it.

I think any kind of time-limited removal that you pronounce in advance, 
is irrational.


"My grandmother used that" is not a good reason.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Ian Jackson]

Vincent Bernat writes ("Re: Bug#835507: Please clarify that sysvinit support 
decision is not going to expire"):
> Maybe sysvinit users (and advocates) could answer to the current RFA on
> src:sysvinit (#811377). None of the people who volunteered half a year
> ago seemed to have carried on despite some good will. Latest uploads are
> all NMU from systemd people.

Hrm.  Thanks for the prompt.  I have subscribed to the PTS for
sysvinit, at least.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Holger Levsen]

On Fri, Aug 26, 2016 at 10:05:46PM -0700, Josh Triplett wrote:
> The reaction to every single instance of someone finding it a pain to
> maintain sysvinit support should not be "as a reminder, the TC has a
> giant hammer and will hit you with it".  The reaction should be "are
> there people willing to *help* maintain sysvinit compatibility, who
> actually use it, who will notice when it breaks, and who will send
> patches?"

I agree.
 
> I do think that developers (*not* the TC) with an interest in sysvinit
> support should explicitly say that if anyone needs help maintaining
> sysvinit support for their package, they'd be willing to volunteer to
> provide such help. 

I agree.

> Anyone willing to volunteer for that?

I haven't found anybody personally volunteering for that. I just have
seen people saying that (other) people should (or will) do that.

So: do we have anyone, someone(s) who are volunteering to fix any bug
with init scripts in any package? Please raise your hands.


btw, somebody should also do something about #832508 ("O: systemd-shim)
I believe.

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Vincent Bernat]

 ❦ 26 août 2016 15:14 CEST, Ian Jackson  :

> Otherwise sysvinit users (and advocates) have to have tiresome
> discussions one package at a time - discussions where the maintainer
> inevitably starts repeating the claims that sysvinit is obsolete and
> should be thrown away now.

Maybe sysvinit users (and advocates) could answer to the current RFA on
src:sysvinit (#811377). None of the people who volunteered half a year
ago seemed to have carried on despite some good will. Latest uploads are
all NMU from systemd people.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Josh Triplett]

On Fri, 26 Aug 2016 14:14:25 +0100 Ian Jackson 
 wrote:
> Sam Hartman writes ("Re: Bug#835507: Please clarify that sysvinit support 
> decision is not going to expire"):
> > I don't want to make a blanket statement that it's a bug not to include
> > an init script.  The systemd package includes a number of daemons and
> > services and installs no init scripts, and no really, that actually is
> > the right answer for that package.  Policy should basically means bug of
> > normal severity.  (I've always wished that the policy people would be a
> > bit more nuanced especially when taking a term from RFC 2119, which
> > more-or-less already includes the nuanced language they need, but
> > people seem to do a fairly good job of accepting the nuances even though
> > that's not quite what policy says.)
> 
> You could say that missing sysvinit support is a bug unless there's a
> good reason why this particular package ought not to support sysvinit.

This seems like a completely reasonable thing for Policy to say.  It
actually doesn't say that today (see Policy 9.11), but I think it
should.

Assuming Policy does say that, then that seems like a sufficient
justification to 1) file a bug and 2) provide or seek out help fixing
that bug.  (Right now, Policy provides enough justification to file a
"Severity: serious" bug, but that doesn't seem reasonable; a
normal-severity bug does, though.)

In the case of conntrack-tools, has anyone actually filed a bug, or
offered to help?

> > I think including 6.1.5 language saying that we encourage maintainers to
> > merge patches adding support for init systems including init scripts
> > would be valuable.
> 
> That would be good.
> 
> I think what is really needed is a clear statement from the TC that
> support for sysvinit should not be regarded as transitional or
> time-limited.

That's a question of available volunteer time.  I don't think sysvinit
support should be regarded as "time-limited"; I don't, for instance,
think "that was two years ago" in isolation serves as a reasonable
argument for ignoring sysvinit.  However, I do think it's reasonable to
expect people who want it to work to provide assistance keeping it
working.  For instance, if someone filed a bug on the sysvinit support
in a package, it seems reasonable for the maintainer to tag it "help".

And if upstream of a package starts requiring systemd and drops support
for sysvinit, I think it's reasonable for a maintainer to send a note to
debian-devel and similar asking for volunteers to maintain a version of
that software with sysvinit support, and to talk with those volunteers
about what shape that maintenance should take (e.g. working with
upstream, providing a new upstream, providing patches to the existing
pakage).  Dropping such support the moment upstream does without any
warning seems unreasonable.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Josh Triplett]

On Fri, 26 Aug 2016 12:55:56 +0100 Ian Jackson 
 wrote:
> So: would the TC please clarify that the decision that
> 
> For the record, the TC expects maintainers to continue to support
> the multiple available init systems in Debian.  That includes
> merging reasonable contributions, and not reverting existing
> support without a compelling reason.
> 
> still stands, and that the answer to this queston
> 
>However, that was two years ago. How long should we be expected to
>continue maintaining sysvinit scripts?
> 
> is "indefinitely, and specifically until a contrary decision by the
> TC" (subject to quibbles over the exact meaning of "maintaining").
> 
> Or to put it another way:
> 
>   The answer to "is missing sysvinit support a bug" is "yes, and
>   it will continue to be regarded as a bug until further notice".
> 
>   Of course a maintainer is not required to personally fix every bug,
>   but a maintainer should not introduce bugs without good reasons, and
>   should merge reasonable bugfix contributions.

Policy *already* defines it as a bug (in terms of failing a "must") to
not supply sysvinit support.  Quoting Policy 9.11:
> any package integrating with other init systems must also be
> backwards-compatible with sysvinit by providing a SysV-style init
> script with the same name as and equivalent functionality to any
> init-specific job, as this is the only start-up configuration method
> guaranteed to be supported by all init implementations. An exception
> to this rule is scripts or jobs provided by the init implementation
> itself

If anything, Policy needs some fixes to even allow for the *possibility*
of packages that can only work with systemd.  There's no current
exception in Policy that allows for packages that specifically depend on
systemd functionality unavailable in sysvinit.  For instance, a package
that uses socket activation and intentionally has no support for running
as a standalone daemon would likely want to integrate with inetd as an
alternative rather than integrating with sysvinit, but Policy doesn't
actually allow a package to do that.  Today it'd be a Policy violation
to ship a package that supports running via either systemd or inetd,
because running via systemd triggers Policy 9.11 and thus requires a
"SysV-style init script", even when that wouldn't be appropriate.

The reaction to every single instance of someone finding it a pain to
maintain sysvinit support should not be "as a reminder, the TC has a
giant hammer and will hit you with it".  The reaction should be "are
there people willing to *help* maintain sysvinit compatibility, who
actually use it, who will notice when it breaks, and who will send
patches?"

And the answer to "how long should we continue maintaining sysvinit
scripts" is "as long as someone is willing to step up and do the work".
(That's also, for instance, the answer to "how long should we maintain
an architecture", and many other similar questions.)

I do think that developers (*not* the TC) with an interest in sysvinit
support should explicitly say that if anyone needs help maintaining
sysvinit support for their package, they'd be willing to volunteer to
provide such help.  Anyone willing to volunteer for that?

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Ansgar Burchardt]

On Fri, 2016-08-26 at 12:38 -0400, Sam Hartman wrote:
> "Ansgar" == Ansgar Burchardt  writes:
> 
> Ansgar> On Fri, 26 Aug 2016 08:50:13 -0400 Sam Hartman wrote:
> >> I think we want to reaffirm that policy section 9.3.2 and
> section
> Ansgar> 9.3.3
> >> represent current policy for init scripts, quoting
> particularly
> >> the following text from section 9.3.2:     Packages that
> >> include daemons for system services should place
> Ansgar> scripts
> >>   in `/etc/init.d' to start or stop services at boot time
> or
> Ansgar> during a
> >>   change of runlevel.
> 
> Ansgar> Does this really represent current policy?
> 
> Ansgar> As far as I can tell Policy still assumes that sysvinit
> is
> Ansgar> the default init system and everything else is an
> "alternate
> Ansgar> init system" (9.11).
> 
> There are many problems with regard to policy and init systems.  I
> believe that 9.3.2 on init scripts and 9.3.3 on update-rc.d are still
> our current policy and still solid.

I don't think so.  There is the larger issue that 9.3 only describes
init.d scripts, but doesn't mention the current default init system at
all.  But even for just describing those init.d scripts, it looks
fairly outdated:

Policy 9.3.3 looks really outdated: it talks about sequence numbers and
one should ask on d-devel@ to choose the right one; it also says that
update-rc.d will start services in runlevels 2-5 and stop them in 0,1,6
by default.  However the default runlevels and sequence numbers are
taken from the (required) LSB comments (directly or indirectly).  These
special comments are not mentioned anywhere.

How invoke-rc.d is invoked is also slightly outdated (the `which
invoke-rc.d` part), although there is a bug against Policy to drop that
bit.

9.3.2 suggests that editing the init script is neccessary to disable a
service without de-installing it: they are configuration files "to
disable a service without de-installing the package". That is a bad
example.

The `status` and `force-stop` options are not mentioned anywhere
(invoke-rc.d mentions them).  Though this is a minor issue.  Having
`try-restart` (from LSB) would also be nice...  It would also be nice
if "behave sensibly" would be better defined (for example LSB has
standard exit codes).

9.4 also looks outdated.  The functions in /lib/lsb/init-functions
should be used if consistent output is desired (as far as I know it
defaults to a different look for the messages, see /lib/lsb/init-
functions.d/20-left-info-blocks).

Init scripts should also really use /lib/lsb/init-functions which makes
supporting alternatives easier (take for example
/lib/lsb/init-functions.d/40-systemd).

Ansgar

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Sam Hartman]

> "Ansgar" == Ansgar Burchardt  writes:

Ansgar> On Fri, 26 Aug 2016 08:50:13 -0400 Sam Hartman wrote:
>> I think we want to reaffirm that policy section 9.3.2 and section
Ansgar> 9.3.3
>> represent current policy for init scripts, quoting particularly
>> the following text from section 9.3.2:     Packages that
>> include daemons for system services should place
Ansgar> scripts
>>   in `/etc/init.d' to start or stop services at boot time or
Ansgar> during a
>>   change of runlevel.

Ansgar> Does this really represent current policy?

Ansgar> As far as I can tell Policy still assumes that sysvinit is
Ansgar> the default init system and everything else is an "alternate
Ansgar> init system" (9.11).

There are many problems with regard to policy and init systems.  I
believe that 9.3.2 on init scripts and 9.3.3 on update-rc.d are still
our current policy and still solid.

The rest of policy in this area really needs to be updated, but if you
see specific problems with those sections, please explain them.  I did a
complete review this morning and they seemed fine to me, especially if
you take more of an RFC 2119 interpretation of SHOULD than we
classically have admitted we take in policy.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Ansgar Burchardt]

On Fri, 26 Aug 2016 08:50:13 -0400 Sam Hartman wrote:
> I think we want to reaffirm that policy section 9.3.2 and section
9.3.3
> represent current policy for init scripts, quoting particularly the
> following text from section 9.3.2:
> 
>  Packages that include daemons for system services should place
scripts
>  in `/etc/init.d' to start or stop services at boot time or
during a
>  change of runlevel.

Does this really represent current policy?

As far as I can tell Policy still assumes that sysvinit is the default
init system and everything else is an "alternate init system" (9.11).

I don't think Policy in its current form should be reaffirmed, but
should be updated to the current time instead. It should certainly
reflect that we changed the default init system some time ago (note
that Policy doesn't mention systemd anywhere).

(Related to that, Policy currently requires *all* packages to ship
sysvinit scripts that integrate with any alternative init system which
I am fairly sure also isn't current policy...)

Ansgar

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[gregor herrmann]

On Fri, 26 Aug 2016 14:14:25 +0100, Ian Jackson wrote:

> Sam Hartman writes ("Re: Bug#835507: Please clarify that sysvinit support 
> decision is not going to expire"):
> > Ian, quick question for you because you might know the answer off the
> > top of your head.  Does running stretch with sysvinit as your init
> > system work reasonably well, or at least work well enough that there are
> > a small number of bugs we will likely be able to fix in the stretch time
> > frame?  What I say below is predicated on the assumption that init
> > scripts are basically functional for stretch.  If that's not true I'd
> > need to rethink my position.
> I am running stretch with sysvinit on my laptop.  It seems to work for
> me.  I haven't conducted any kind of systematic survey.

FWIW, I'm also running sysvinit on a couple of machines which are
following stretch or sid, and it seems to work fine for me.
 

Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Europe: The Final Countdown


signature.asc
Description: Digital Signature

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Ian Jackson]

Sam Hartman writes ("Re: Bug#835507: Please clarify that sysvinit support 
decision is not going to expire"):
> [Ian Jackson:]
> > I am running stretch with sysvinit on my laptop.  It seems to
> > work for me.  I haven't conducted any kind of systematic
> > survey.
> 
> That's the rough estimate I thought you could provide easily and was
> looking for.

Good.  Thanks.

> That's good enough that I definitely support reaffirming policy 9.3.2
> and 9.3.3.

Thanks.


I don't know if you want to include in your resolution a list of
examples of things which are NOT good reasons to drop sysvinit
support.

Such bad reasons, which have been advanced on debian-devel, include:

 * The maintainer does not have a system running sysvinit to use
for testing and development of the sysvinit scripts.

 * The package only supports Linux.

 * The package has really good systemd integration.

 * "It's time to let sysvinit die".  (In some cases phrased as "the TC
   decision was 2 years ago" or some such.)

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> Sam Hartman writes ("Re: Bug#835507: Please clarify that
Ian> sysvinit support decision is not going to expire"):
>> Ian, quick question for you because you might know the answer off
>> the top of your head.  Does running stretch with sysvinit as your
>> init system work reasonably well, or at least work well enough
>> that there are a small number of bugs we will likely be able to
>> fix in the stretch time frame?  What I say below is predicated on
>> the assumption that init scripts are basically functional for
>> stretch.  If that's not true I'd need to rethink my position.

Ian> I am running stretch with sysvinit on my laptop.  It seems to
Ian> work for me.  I haven't conducted any kind of systematic
Ian> survey.

That's the rough estimate I thought you could provide easily and was
looking for.

That's good enough that I definitely support reaffirming policy 9.3.2
and 9.3.3.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Ian Jackson]

Sam Hartman writes ("Re: Bug#835507: Please clarify that sysvinit support 
decision is not going to expire"):
> Ian, quick question for you because you might know the answer off the
> top of your head.  Does running stretch with sysvinit as your init
> system work reasonably well, or at least work well enough that there are
> a small number of bugs we will likely be able to fix in the stretch time
> frame?  What I say below is predicated on the assumption that init
> scripts are basically functional for stretch.  If that's not true I'd
> need to rethink my position.

I am running stretch with sysvinit on my laptop.  It seems to work for
me.  I haven't conducted any kind of systematic survey.

> I don't want to make a blanket statement that it's a bug not to include
> an init script.  The systemd package includes a number of daemons and
> services and installs no init scripts, and no really, that actually is
> the right answer for that package.  Policy should basically means bug of
> normal severity.  (I've always wished that the policy people would be a
> bit more nuanced especially when taking a term from RFC 2119, which
> more-or-less already includes the nuanced language they need, but
> people seem to do a fairly good job of accepting the nuances even though
> that's not quite what policy says.)

You could say that missing sysvinit support is a bug unless there's a
good reason why this particular package ought not to support sysvinit.

> I do *not* want to get into describing all the cases where it is a bug
> to not include an init script, nor do I want to get into all the cases
> where it isn't.

I don't think that's necessary.  The situations where this is causing
friction (see debian-devel) are not the unusual cases where the
package is part of systemd (or indeed is glue for another init system
- see what's done in a few cases for runit).

A statement of the general idea, even with a broad room for
exceptions, would be sufficient.

> I think including 6.1.5 language saying that we encourage maintainers to
> merge patches adding support for init systems including init scripts
> would be valuable.

That would be good.

I think what is really needed is a clear statement from the TC that
support for sysvinit should not be regarded as transitional or
time-limited.

Otherwise sysvinit users (and advocates) have to have tiresome
discussions one package at a time - discussions where the maintainer
inevitably starts repeating the claims that sysvinit is obsolete and
should be thrown away now.

In the political context of the init system wars, those kind of
statements are extremely agressive.  Coupled with the fact that the
maintainer is in a position of power, this generates justifiable fear
and anger in systemd's opponents.

So, sadly, I think the TC needs to reiterate and reinforce its earlier
general message.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Sam Hartman]

Ian, quick question for you because you might know the answer off the
top of your head.  Does running stretch with sysvinit as your init
system work reasonably well, or at least work well enough that there are
a small number of bugs we will likely be able to fix in the stretch time
frame?  What I say below is predicated on the assumption that init
scripts are basically functional for stretch.  If that's not true I'd
need to rethink my position.


I think we want to reaffirm that policy section 9.3.2 and section 9.3.3
represent current policy for init scripts, quoting particularly the
following text from section 9.3.2:

 Packages that include daemons for system services should place scripts
 in `/etc/init.d' to start or stop services at boot time or during a
 change of runlevel.
I think it is also reasonable to reaffirm that this is Debian policy
 until changed through the policy process or by the TC.

I don't want to make a blanket statement that it's a bug not to include
an init script.  The systemd package includes a number of daemons and
services and installs no init scripts, and no really, that actually is
the right answer for that package.  Policy should basically means bug of
normal severity.  (I've always wished that the policy people would be a
bit more nuanced especially when taking a term from RFC 2119, which
more-or-less already includes the nuanced language they need, but
people seem to do a fairly good job of accepting the nuances even though
that's not quite what policy says.)

I do *not* want to get into describing all the cases where it is a bug
to not include an init script, nor do I want to get into all the cases
where it isn't.  The TC tried to do that during the systemd discussion
with text for the L and T varients of options.
I think they did about as well as they could, but I think a policy
should better captures the reality of the situation than the TC's
previous best efforts.

I think including 6.1.5 language saying that we encourage maintainers to
merge patches adding support for init systems including init scripts
would be valuable.
I think we have such language floating around from previous resolutions
to re-use.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Ian Jackson]

Package: tech-ctte

There has recently been a thread on debian-devel ("Is missing
SysV-init support a bug?) about the decision by a package maintainer
to drop sysvinit support from their package.  The maintainer has said
they are reconsidering, which is good.

But, the discussion on -devel has shown that there are some other
maintainers who are considering similar steps, and that the project's
view on this is not settle.

So: would the TC please clarify that the decision that

For the record, the TC expects maintainers to continue to support
the multiple available init systems in Debian.  That includes
merging reasonable contributions, and not reverting existing
support without a compelling reason.

still stands, and that the answer to this queston

   However, that was two years ago. How long should we be expected to
   continue maintaining sysvinit scripts?

is "indefinitely, and specifically until a contrary decision by the
TC" (subject to quibbles over the exact meaning of "maintaining").

Or to put it another way:

  The answer to "is missing sysvinit support a bug" is "yes, and
  it will continue to be regarded as a bug until further notice".

  Of course a maintainer is not required to personally fix every bug,
  but a maintainer should not introduce bugs without good reasons, and
  should merge reasonable bugfix contributions.

Thanks,
Ian.