Sam Hartman writes ("[draft] Draft text on Init Systems GR"):
> This is a draft GR. I hope to be at a point where I could formally
> propose a GR in a week, assuming discussion converges that fast.
I don't think these options really answer the key questions clearly.
I am going to propose a draft text, but for now I will write what I
think are the four key issues:
Issue 1. What about init scripts ? Do maintainers have to write init
scripts ? What if we don't have an init script ?
Right now not having an init script is nominally an RC bug, although
no-one is filing these bugs. I think this is largely because just
filing RC bugs is just fighting. It doesn't lead to any good outcome.
I have a suggestion which might be radical for Debian but seems to
deal with this nicely:
Lack of an init script is a bug, the same way lack of a manpage is
(etc. etc.) Mostly we don't even file these bugs.
But it is an *RC bug if the bug provides a patch*. (There are some
details to be dealt with here, eg what if the patch is broken.)
This would encourage people to submit patches, if they care. If you
could submit a patch with RC severity and knew that that severity was
the project's will, you could expect the maintainer to apply it; if
the maintainer was away or whatever you could NMU it.
OTOH it discourages the useless approach of just filing bugs without
patches.
(We don't need to do the same thing with manpages because maintainers
just apply manpage patches. No-one is trying to abolish manpages yet,
at least not enough to reject manpage patches.)
Issue 2. What about non-directly-pid-1-related systemd features like
tmpfiles.d, sysusers.d ?
We are currently using dh stuff for this mostly. That results in
scripts in packages. Over the many years we have singularly failed to
make declarative features in dpkg for this, or indeed in anything
else.
I *do* like the idea of declarative syntax. The difficulties for
non-systemd systems, with many of these features, are not inherent.
Often the specifications don't depend on systemd as pid 1 or on
logind. Or they have sensible subsets which would be fine and which
we could adopt.
I guess that the project as a whole wants to move forward on this. I
think we need to find a way to do it. There are some obstacles we
need to overcome but I think I have wording that deals with most of
them.
I think it is fair to ask the non-systemd folks (like me) to implement
these interfaces, provided that that's only a reaonable amount of work
and provided that change management is in Debian's hands.
Issue 3. Blocking behaviours.
I don't want to provide specific references, but I have seen more than
one effectively-content-free RC bug filed against a component of the
non-systemd ecosystem. There have been some other attempts to get
stuff removed as "obsolete".
And then there is the situation with updating Policy to recognise
systemd as the default, and describe unit files etc., for example.
I am hoping that some general words, and a good majority in a GR, will
help to alleviate these problems. A show of political will by the
project would probably make it difficult to sustain these kind of
blocks.
Issue 4. Hateful stuff on our lists etc.
I have tried to capture what kinds of statements are the key problem
here. I think we need to clearly tell our listmasters etc. what we
expect, since enforcement action they take needs clear legitimacy.
Ian.
