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

Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)

Le jeudi, 6 février 2014, 10.50:05 Colin Watson a écrit :
> On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote:
> > L really reads to me like a way to enforce support for all init
> > systems alike (thereby ensuring that the default init gets the same
> > [bad] support) on maintainers and I feel it's too coercitive.
> I don't interpret L as meaning that everything must support "all" init
> systems, certainly not "alike" (indeed the text of that option is
> explicit that it isn't necessarily alike).  Rather, I interpret it as
> saying that software-outside-init must be flexible enough to cope
> with that possibility, and degrade sensibly to a lowest common subset
> of init system features (IOW in practice, needs to keep working if
> sysvinit is pid 1).

L doesn't say anything about lowest common subset, it says "may not 
require a specific init system", which is different.

> > * L would enforce that any software can run on all inits (failure to
> >   work on one is equivalent to requiring any of the other ones, henc
> >   failing the requirement of L)
> That's not how I interpret it.  "A specific init system" is in the
> singular.

In the case of interpreting L with "specific init" being singular, then 
a package requiring any of OpenRC and systemd would fit L as it doesn't 
require a specific init, but any within a set. If upstart would be taken 
as default, that's certainly not the intent of L, right?

> I'm not worried that we'll end up with cases where software-outside-
> init somehow manages to work with two init systems but not the others;
> working with more than one indicates the basic flexibility that I want
> to see, and the rest is up to developers who care about init systems.

That's not what the L option says, again. Let's take logind as example 
(instead of inventing pseudo-test-cases). There are two views:

* logind is considered part of "systemd to be pid 1". L says you can't 
depend on any init being pid 1; L therefore imposes the maintainers of 
all software using logind to maintain interfaces to be working on non-
systemd-inits (runtime-detection of [deprecated] ConsoleKit !?)
* logind is not considered part of "systemd to be pid 1" (the existence 
of a second implementation seems to suggest that), then software can 
depend on having logind available. How the "logind interface" is defined 
is mostly a matter of having maintainers of the various providers agree 
on virtual package names. That said, this view would make "systemd-
logind" fall under L, imposing on its maintainers to make it work on 
non-systemd inits.

I think L is putting the burden of maintenance wrongly in these two 
cases (on all consumers of logind or on the systemd-logind maintainers).

> >     "All but specific packages are expected to work with the default
> >      init system. However, where feasible, packages should
> >      interoperate
> >      with all init systems; maintainers are encouraged to accept
> >      technically sound patches to enable interoperation, even if it
> >      results in degraded operation while running under the init
> >      system
> >      the patch enables interoperation with."
> Doesn't that just move the question to what the "specific packages"
> are, the scope of which is the core of the difference between T and L
> anyway?

Not in my view. It lets the individual maintainers decide whether their 
package is a sufficiently specific case. It also reinforces the role of 
the "default" init with regards to other non-defaults, explicitly ruling 
the "init islands" out. Any disagreement on the "specificity" can 
subsequently be referred to the TC, of course.

What I tried to express in my earlier mail is that I think both T and L 
are simultaneously too vague and too specific: they both try to tell the 
Gnome maintainers (and others, of course) what they should or must do 
with regards to logind-being-tied-to-systemd, without explicitely 
writing it (too specific), while failing at making explicit that the 
default init should be supported (too vague).

I also think they are both spelled in a way that assumes that 
maintainers would act in bad faith with regards to either upstart or 
systemd support in the cases where each wouldn't be taken as default.

Finally, I have hard time seeing under which powers could L be decided 
by the tech-ctte: the policy team hasn't worked on that (§6.1.1), there 
is no juridiction overlap that I could see (nor a disagreement about the 
matter, §6.1.2), and it's not formulated as an overrule (§6.1.4) or an 
advice (§6.1.5). The only relevant bit would be §6.1.3 as Paul 
specifically asked for in <20131025184344.GB4599@helios.pault.ag>:

> (…) and make a judgement call on where the efforts to resolve this
> situation shall go (patching *around* the lack of systemd, or patching
> software to use systemd)

Paul's request is about a "judgement call on where the efforts (…) shall 
go", not about setting technical policy. L, in its current state is too 
far-reaching in forbidding package relationships while the policy team 
hasn't worked on the matter yet.

Therefore, I stand by my objection: both T and L should be dropped from 
the tech-ctte resolution. A text reminding that support for the default 
init is expected wouldn't hurt though…


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: