[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: Init system resolution open questions



Adrian Bunk <bunk@stusta.de> writes:
> On Sat, Jan 18, 2014 at 09:45:35AM -0800, Russ Allbery wrote:

>> If software that people want to package for Debian is deeply entangled
>> in one init system (that is supported in Debian), for good or for ill,
>> regardless of what one might think of the decisions made by upstream
>> that created that situation, I think it's going rather far to require
>> the Debian package maintainers to port it to different init systems in
>> order to get (or keep) their package in Debian.  I have a very hard
>> time defending that position.

> So in the hypothetical case that systemd upstream decides to make udev 
> hard depend on systemd being pid 1, would you even defend that such a
> change could go into jessie if the CTTE decision was that Debian should
> support multiple init systems?

It would, of course, depend on *why* they made that decision, but at least
on the surface that seems like it would prevent us from either supporting
multiple init systems or having a reasonable upgrade from sysvinit.  Those
would both be significant drawbacks, so I think in such a situation we
should look for alternatives.  (And I know the udev maintainer really
wants to require a modern init system -- that was one of the messages that
set off this discussion -- but I do think it would be worthwhile waiting
until after jessie to take that step.)

You may be noticing a theme here: I'm refusing to take hard positions, in
advance, on theoretical future possibilities.  I think that's part of the
responsibility of the Technical Committee.  See 6.3.6:

    Technical Committee makes decisions only as last resort.

    The Technical Committee does not make a technical decision until
    efforts to resolve it via consensus have been tried and failed, unless
    it has been asked to make a decision by the person or body who would
    normally be responsible for it.

I believe the spirit of that provision includes not borrowing trouble for
ourselves by making definitive statements about future events that may or
may not happen.  Remember, the context of this discussion is around
whether the Technical Committee, assuming that we choose systemd as a
default, will require that all software in Debian that's part of the
jessie release work with sysvinit as well.  I'm pointing out edge cases
and possible drawbacks to making a firm and sweeping statement without
knowing, in advance, *why* some piece of software doesn't work with
sysvinit.  Other people have pointed out other cases, such as software
that was never part of previous releases and hence doesn't pose upgrade
issues.

> We are in full agreement on that.

> And my point on top of that is that if the CTTE decsion would be that
> Debian should support multiple init systems, but it does not set a
> policy limiting strictly what hard dependencies on systemd are allowed,
> then it would be better if the CTTE would rule that Debian should
> support only systemd since that's what would anyway happen in practice
> through package dependencies pretty soon.

And yet there are still people who use Debian without udev (or at least I
think there is based on debian-devel discussion).  Why go out of our way
to tell those people to go away?

There is a natural process here, where rarely-used configurations slowly
stop working and people eventually decide not to bother to keep them
working and move on to other things.  Eventually, they may acquire RC bugs
that no one wants to fix and be dropped, or the package maintenance team
may decide that they just can't support the configuration any more, make a
public call for people to step forward and maintain it, and, when that
call isn't answered, drop support.

The drawback of trying to short-circuit that process is that it's quite
easy to guess wrong and decide to proactively drop support for something
that turns out to not be that hard to continue to support, or that someone
else wants to support and is willing to do all the work to support.  I'd
rather leave it to the expert analysis of the people directly involved,
and don't want to skip past the courtesy of inviting people to find a way
to fix the problem if they care about it.

To take another example, do you think the Technical Committee should have
said that file-rc is not supported?  I don't see why we should make that
sort of proactive statement.  Yes, it doesn't work very well, and has some
problems, but people have still been using it, and people are still
willing to fix problems with it, so why go out of our way to tell those
people to stop?

In other words, I would rather be clear about what we consider to be the
primary technical direction, and the core functionality that we should try
to support, and let the long tail and personal projects take care of
themselves.  Some of them will fade away, some of them will putter along
in the background without hurting anyone, and we may be quite surprised by
one of them becoming a huge asset to the project later on.  That's why I
like the framing of this discussion as deciding the *default*.

> If Debian wants to support multiple init systems and wants to continue
> supporting non-Linux ports, then Debian's policy must force Debian
> maintainers to put pressure on their upstreams to keep support for
> non-systemd systems and for non-Linux kernels.

Sort of.  But I don't think that level of pressure is necessarily higher
than the pressure we've been putting on upstream to support Hurd for
years, which has amounted to a small stream of patches that are generally
unobjectionable.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: