Bug#727708: call for votes on default Linux init system for jessie
On Tue, 2014-01-28 at 22:20 +0200, Adrian Bunk wrote:
> On Tue, Jan 28, 2014 at 12:08:19PM -0800, Don Armstrong wrote:
> > On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
> > > > The former. So :
> > > >
> > > > Where feasible, software should interoperate with non-default init
> > > > systems; maintainers are encouraged to accept technically sound
> > > > patches to enable interoperation, even if it results in degraded
> > > > operation while running under the non-default init.
> > >
> > > Maybe I'm dense...
> > >
> > > Scenario: Let's say that OpenRC is the new default init and in the
> > > meanwhile, Gnome has gained a dependency on systemd. A patch to
> > > support Upstart in Gnome is posted that partially breaks the
> > > functionality under systemd.
> > >
> > > By your wording, maintainers are encouraged to accept the patch.
> >
> > No. This was precisely the ambiguity which Neil (correctly) pointed out.
> > Simply put, patches which reduced existing functionality while running
> > under the default init (say, systemd), would not be technically sound.
> >
> > Instead, maintainers are encouraged to accept the patch even if it
> > results in reduced functionality while running under the non-default
> > init (say, upstart) in comparison to the default init (say, systemd).
>
> That's a different case.
>
> Zbigniew was talking about a package that has a dependency on a
> *non*default init system.
>
> And for that the first question is whether such a dependency on a
> *non*default init would be allowed at all.
Not really. What Zbigniew was talking about was whether the above
wording would allow a patch enabling operation with system A to degrade
existing functionality with *another* system B (whether B is actually a
strict "dependency" does not seem that important). This depends on how
you interpret "the non-default init"; Don obviously meant this to refer
to the same init as the patch is for.
I think this kind of possible ambiguity could be avoided by phrasing
like "even if the patch only implements a degraded mode of operation
under this system", to make it clear that the "degrade" does not refer
to any functionality that existed _before_ the patch.
Reply to: