Bug#727708: init system coupling etc.
On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
> I propose the following text as an amendment to this option. It would
> replace this text in its entirety, including the [GR rider] section. (I
> don't see any need for or purpose served by cancelling technical advice to
> the project based on a GR outcome. All the members of the project are, I
> think, capable of using their own judgement to resolve technical advice
> with the substance of a GR, and technical advice is by definition not
> binding. Plus, I think this is a basically sensible thing to say
> regardless of the chosen init system.)
>
> Please note that I personally am currently leaning towards voting Keith's
> proposal above the one that I'm proposing in this message for the reasons
> that he states in that message. But I think it's useful to have a
> statement on the ballot so that it can be ranked, since it may be a
> compromise position between deferring to the Policy process and Ian's
> proposal.
I think the detail of this option is a good approach; I'd like to see it
on the ballot, and I would currently be inclined to rank something like
this first.
I'm currently undecided about whether I prefer the approach of setting
technical policy under 6.1.1 or offering advice under 6.1.5. Bearing in
mind all the process discussions we've had, I can see that it might be
better to take the approach of offering technical advice rather than
getting (re-)embroiled in a distracting procedural dispute about whether
the Constitution entitles us to rule in advance on a subject that hasn't
clearly been asked of us by some other first-responding maintainer. If
we can establish an advice position that has strong consensus in the
committee (even if not necessarily at first place on this ballot, given
that some committee members would prefer to set technical policy in
advance), then we can always come back to it for reference later if we
should find it necessary to overrule maintainers.
Ian, you said that you don't agree with this amendment. I am guessing
based on your previous statements that you mainly disagree with the
force of it, rather than the substance, but I'm cautious of making
unwarranted inferences or putting words in your mouth. Is this
accurate? I think it would be helpful if we had as much substantive
common ground between the ballot options as possible.
> Packages should normally support the default Linux init system. There
> are some exceptional cases where lack of support for the default init
> system may be appropriate, such as alternative init system
> implementations, special-use packages such as managers for non-default
> init systems, and cooperating groups of packages intended for use with
> non-default init systems. However, package maintainers should be
> aware that a requirement for a non-default init system will mean the
> package will be unusable for most Debian users and should normally be
> avoided.
Some of the details found here would be helpful in L too, and I think
they should be common ground. In particular, several people have noted
the case of something like separate management utilities for a
particular init system which make use of advanced details of its
implementation. I personally have no quarrel with these as long as
users of other init systems are not required to install them in order to
(say) use their desktop environment and keep it updated in a reasonable
way. But it's not clear that these are part of the init system's
implementation, and I would probably argue that they aren't, especially
if (as they might well be) they are maintained by entirely different
people.
To start with, I therefore propose the following amendment to L. I
think it is no weaker except in ways that we would agree were in fact OK
if we found ourselves needing to rule on them specifically, and this
addresses points that people have raised here. The first paragraph of
the "loose coupling" section is replaced by the following:
In general, software may not require a specific init system to be pid
1, although degraded operation is tolerable. The exceptions to this
are as follows:
* alternative init system implementations
* special-use packages such as managers for init systems
* cooperating groups of packages intended for use with specific init
systems
provided that these are not themselves required by other software
whose main purpose is not the operation of a specific init system.
Maintainers are encouraged to accept technically sound patches
to enable improved interoperation with various init systems.
(It took me three goes to draft this in a way I was happy with, so
perhaps more wordsmithing is needed.)
> For the jessie release, all packages that currently support being run
> under sysvinit should continue to support sysvinit unless there is no
> technically feasible way to do so.
"Technically feasible" is so dependent on interpretation that I'm not
sure whether it has enough real meaning. My instinct is to borrow some
of the "exceptional cases" language from an earlier paragraph. On the
other hand, "all packages that currently support being run under
sysvinit" seems to mostly cover this well enough - it just takes me a
couple of readings to get to it. Does this sentence bother anyone else?
Russ, can you give an example of a package that currently supports
sysvinit where you would be happy that it might stop supporting it for
jessie due to a lack of technical feasibility?
I do expect to have some more thoughts on this, and I'd like to ask that
we not rush to a vote while we're still actively throwing around
interesting amendments. I've had a cluster of complicated customer bugs
to deal with at work and have been generally busy in the evenings as
well, so I've not been able to get all the way through my thinking on
this. I would rather not have to vote FD again if it can be avoided in
the discussion period. On the other hand I can understand Ian's wish to
put a time limit on this rather than it dragging on forever. Would an
extra week work for everyone? I don't think too much in the way of
irreversible changes will happen in unstable in that time.
--
Colin Watson [cjwatson@debian.org]
Reply to: