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.gb4...@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… Cheers. OdyX
signature.asc
Description: This is a digitally signed message part.
