Bug#727708: init system coupling etc.
Ian Jackson wrote:
> I suppose what I mean is that a problem which occurs due to "wrong"
> init system is a real problem and should not be reduced in severity or
> excused on the grounds that the particular init system is defined as
> "required" (whether via a dependency or otherwise).
>
> So if the degraded operation amounts to a missing feature (a bug of
> wishlist severity), then that's a bug of wishlist severity (and might
> be closed or tagged "wontfix").
>
> If the degraded operation amounts to a plain bug (ie bug of normal
> severity), then that's a bug of normal severity. Packages with bugs,
> even regressions, are of course routinely uploaded and released.
> Whether to do so is a tradeoff which we leave the maintainer to
> consider.
>
> If the degraded operation amounts to a bug of RC severity, then that's
> a bug of RC severity and the new version of the requiring package
> should be blocked from transitioning to testing, or being released,
> until the problem is fixed, or at least worked around so that it is no
> longer RC.
>
> Is this a suitable approach ? If so then perhaps I should clarify my
> proposed wording.
This approach does solve one problem present in previous proposals, by
clarifying that a bug does not become any *more* severe just because it
involves init systems. However, there are still two notable problems
this doesn't address.
First, on which init systems?. Everything in Debian that provides
/sbin/init, no matter its capabilities or lack thereof? Or some subset
of those implementations, in which case what are the selection criteria
for that subset?
Second, what makes init systems so wildly different from anything else
in Debian that the usual principles don't apply? For any other package,
"doesn't work when its dependencies are replaced" is a wishlist bug.
Such bugs are often fixed, especially when a patch is supplied, but that
doesn't make them any more than wishlist, even though "doesn't work"
would be RC if the package's dependencies are satisfied. That's true
even when the dependencies and their alternatives are packages that
can't coexist on the same running system.
As far as I can tell, the only difference is one of scale: systemd is
poised to provide functionality that far more packages want and might
benefit from depending on, and thus the fear that it will become
irreplaceable is higher. Nonetheless, this still seems like something
that can be handled naturally. People who want to support alternative
init systems can continue to do so; absolutely nothing is stopping them.
As long as that work remains tractable and people want to do it, it'll
find a way to happen; Debian developers are too good at cooperating with
each other for that not to work out. If the work to support any
particular init system across all packages in the archive ever becomes
overwhelming and insurmountable, *that means something*.
It makes sense to ensure that developers or supporters of alternate init
systems can expect a reasonable reception for work they've done to make
packages work with their init system. (I don't see any obvious reason
to expect that won't already happen, but it's certainly reasonable to
debate how best to achieve *that* goal.) However, this proposal instead
suggests that if that work hasn't been done yet by anyone, something has
gone horribly wrong and must be fixed, rather than that a wishlist bug
exists and a patch would sure be nice.
Does a proposal phrasing exist that would satisfy the concerns
motivating this one, addressing the goal of supporting contribution of
support for alternate init systems, without making it a bug for the
maintainer of every package to do the work themselves? Or is it the
intentional aim of this proposal to force package maintainers to do the
work of supporting all init systems themselves or face an RC bug?
(As an aside, while it wouldn't necessarily do everything you want out
of this proposal, I wouldn't be surprised if there's support from the TC
for a proposal of "maintain sysvinit compatibility through jessie, and
support smooth upgrades", which ought to address the concerns that are
motivating your urgency in addressing this issue. Passing such a
resolution would then allow for a more prolonged consideration of how to
handle things post-jessie, as well as consideration of whether existing
cooperative processes in Debian might be able to handle this isue given
the time. Any particular reason *not* to do that?)
- Josh Triplett
Reply to: