Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
Hi Kurt, Le jeudi, 6 février 2014, 21.19:36 Kurt Roeckx a écrit : On Thu, Feb 06, 2014 at 08:38:25PM +0100, Kurt Roeckx wrote: I'm guessing that under you're asking for the interpretation of this in 6.1.1: | In each case the usual maintainer of the relevant software or | documentation makes decisions initially And think that because the policy maintainers didn't try to make any decision yet, the ctte can't make that decisions? Yes. I stand to this interpretation, see below. I'm currently of the opinion that gnome made an initial decisions and as reaction to that they are setting policy and that this will be allowed under 6.1.1. Back then, the gnome maintainers added a dependency on another package, which happened to be providing an /sbin/init. This was allowed by the Debian Policy of the time as well as by the Debian archive. The maintainers of the Policy maintainers haven't tried to rule on this at all since then. How is this matter now magically taken off the Policy maintainers' hands (while it _is_ a matter of Policy) and become a matter for the technical committee? I feel compelled to write that I'm quite concerned to see technical committee members propose to rule on things they see fit, just because it's sufficiently important to their eyes. As I detailed in 1756169.he50hsLr7Y@gyllingar, I'm quite firmly convinced that any ruling restricting software dependencies fails §6.1.1 (as the powers invoked), §6.3.5 and §6.3.6 at this point in time. OdyX signature.asc Description: This is a digitally signed message part.
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
Kurt Roeckx writes (Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)): I'm currently of the opinion that gnome made an initial decisions and as reaction to that they are setting policy and that this will be allowed under 6.1.1. It's clear that whether this kind of dependency is allowed is a key issue (perhaps even _the_ key issue) in this dispute. The question of the default init system is in some ways a proxy for the coupling question. And the extent and timing of such dependencies is clearly a matter that ought to be dealt with in the policy manual. So it is definitely a matter of technical policy. Whether the matter is ripe for the TC is not something that I would expect the Secretary to rule on. I think that's a matter for the TC. (The alternative would be to contemplate the TC making a decision on policy and the Secretary then stating that the TC decision was invalid and of no effect.) But even if it is for the Secretary to rule on, I hope that the Secretary will agree that it's clear that the question is ripe for a TC decision (if not wildly overdue). Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Fri, Feb 07, 2014 at 04:43:33PM +0100, Didier 'OdyX' Raboud wrote: Hi Kurt, Le jeudi, 6 février 2014, 21.19:36 Kurt Roeckx a écrit : On Thu, Feb 06, 2014 at 08:38:25PM +0100, Kurt Roeckx wrote: I'm guessing that under you're asking for the interpretation of this in 6.1.1: | In each case the usual maintainer of the relevant software or | documentation makes decisions initially And think that because the policy maintainers didn't try to make any decision yet, the ctte can't make that decisions? Yes. I stand to this interpretation, see below. I'm currently of the opinion that gnome made an initial decisions and as reaction to that they are setting policy and that this will be allowed under 6.1.1. Back then, the gnome maintainers added a dependency on another package, which happened to be providing an /sbin/init. This was allowed by the Debian Policy of the time as well as by the Debian archive. The maintainers of the Policy maintainers haven't tried to rule on this at all since then. How is this matter now magically taken off the Policy maintainers' hands (while it _is_ a matter of Policy) and become a matter for the technical committee? Do you agree that the ctte can decide policy? Under what conditions? I think it all boils down to what relevant software or documentation means. I feel compelled to write that I'm quite concerned to see technical committee members propose to rule on things they see fit, just because it's sufficiently important to their eyes. As I detailed in 1756169.he50hsLr7Y@gyllingar, I'm quite firmly convinced that any ruling restricting software dependencies fails §6.1.1 (as the powers invoked), §6.3.5 and §6.3.6 at this point in time. About detailed design work: You could argue that they proposed the alternative solutions and aren't just deciding between them. As far as I know those proposols come from the ctte itself, in which case it should probably go under 6.1.5 to give advice. About 6.3.6: I think trying to resolve this via consensus failed. Anyway, I'm still not sure. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
Le vendredi, 7 février 2014, 18.47:51 Kurt Roeckx a écrit : Back then, the gnome maintainers added a dependency on another package, which happened to be providing an /sbin/init. This was allowed by the Debian Policy of the time as well as by the Debian archive. The maintainers of the Policy maintainers haven't tried to rule on this at all since then. How is this matter now magically taken off the Policy maintainers' hands (while it _is_ a matter of Policy) and become a matter for the technical committee? Do you agree that the ctte can decide policy? Under what conditions? For the general question of deciding policy, I think the following articles are relevant: * § 6.1.1 says In each case the usual maintainer of the relevant (…) documentation makes decisions initially * § 6.3.6 says Technical Committee makes decisions only as last resort In the specific case of deciding what types of software requirements are acceptable in Debian, which I think is of the responsibility of the Policy team, then the tech-ctte can decide policy only if the Policy team (aka maintainer of the relevant documentation) has made an initial decision (6.1.1) or has delegated one of its decisions to the tech-ctte (6.1.3). Any of the proposed L or S would certainly impose amendments of various parts of the Debian Policy (I could think of 2.2.1, 3.5, and certainly 9.11); that makes them quite clearly of the Debian Policy Team realm. If the decision could come in force through another way, that would be through amending the definition of bug severities, but that would be quite odd. I think it all boils down to what relevant software or documentation means. Clearly. L and S amend what software requirements are acceptable in Debian, for which the only limit we've had until now was the DFSG and the Debian Policy. I feel compelled to write that I'm quite concerned to see technical committee members propose to rule on things they see fit, just because it's sufficiently important to their eyes. As I detailed in 1756169.he50hsLr7Y@gyllingar, I'm quite firmly convinced that any ruling restricting software dependencies fails §6.1.1 (as the powers invoked), §6.3.5 and §6.3.6 at this point in time. About detailed design work: You could argue that they proposed the alternative solutions and aren't just deciding between them. Yes, that's what I'm saying. As far as I know those proposols come from the ctte itself, in which case it should probably go under 6.1.5 to give advice. I'd be totally fine with the tech-ctte giving advice under 6.1.5. In this case it should only be formulated _as_ an advice, such as: We think that software outside of an init system'simplementation should not require a specific init system to be pid 1, although degraded operation would be tolerable. That would be clearly non-binding. About 6.3.6: I think trying to resolve this via consensus failed. I agree that attempts at deciding about the default init via consensus failed, and I am definitely looking forward to a decision, it's long due. I disagree that attempts at deciding what software requirements with regards to init systems are acceptable in Debian have failed: I don't think they have started at all in the forum where they should have: the Policy Team. (It's probably because in the absence of a decision, there's not much to discuss yet!) Finally, I think that ruling on these specifics now is not constitutionally in the hands of the technical committee, terribly premature, and assumes bad faith from a quite wide set of Debian package maintainers and upstream authors. The latter is what puzzles me most. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Fri, Feb 07, 2014 at 04:01:12PM +, Ian Jackson wrote: Kurt Roeckx writes (Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)): I'm currently of the opinion that gnome made an initial decisions and as reaction to that they are setting policy and that this will be allowed under 6.1.1. It's clear that whether this kind of dependency is allowed is a key issue (perhaps even _the_ key issue) in this dispute. The question of the default init system is in some ways a proxy for the coupling question. And the extent and timing of such dependencies is clearly a matter that ought to be dealt with in the policy manual. So it is definitely a matter of technical policy. I don't think anybody is arguing that it's not technical policy. Whether the matter is ripe for the TC is not something that I would expect the Secretary to rule on. I think that's a matter for the TC. (The alternative would be to contemplate the TC making a decision on policy and the Secretary then stating that the TC decision was invalid and of no effect.) I think we all want to avoid that I have to retract the decision and so maybe it's best that we try to find the answer before the vote. Anyway, I've already been asked about this, so I see little point in waiting. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
Sorry for yet-another-mail on that (long-lasting) bug, but I feel it's important; so feel free to dismiss it if it isn't bringing to the conversation. Le jeudi, 6 février 2014, 16.27:15 Anthony Towns a écrit : Rankings between remaning actual outcomes is: 4x UL DL UT DT (steve, colin, ian, andi) 2x DT DL UT UL (russ, don) So that's UL DL DT 4:2 UL UT DT 4:2 DL UT 6:0 I'm quite puzzled by this (partial) result, generally ranking the L variants over the T's. I think letting any L variant win would create quite a precedent on what software is allowed in Debian. Software doesn't imply package and is loosely defined, the same goes for degraded operation. Is KDE a software, or are all of its independent parts softwares? Would failure to suspend under OpenRC be an acceptable degraded operation of the whole KDE or only of its upower/Solid/whatever component? 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. On the other hand, T apparently brings in the fear of archive fragmentation by allowing the various init islands to develop on their own. Now, I think there is currently a shared agreement in Debian that all Debian packages (unless there's a good reason) should run on sysvinit + Linux + amd64 , support outside that is best-effort Now, I think this default init decision's purpose is to change the above agreement by replacing the syslinux in the above sentence by one of the contenders. Both the T and L riders purposedly don't say anything about the default init, and I think that's wrong: * T would permit islands outside of the default init (while I think that some prefer it because it allows the default init island to be technically sane) * 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) The common agreement above stood until packages started to depend on systemd, which in the end, lead to the opening of this bug. I think the technical committee resolution on this issue should focus on outlining what the new deal should be, without stepping into defining what set of init systems the software shipped by Debian should or must support: the resolution should be limited to deciding what the new default init will be. Now, if there are concerns of eventual bad faith from the maintainers, the resolution could include something outlining the boundaries of the common agreement such as (which I think is the current consensus): 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. That (or any consensual phrasing along these lines) would completely replace both the T and L riders and be part of the resolution deciding which init system will be the default. I think that would vastly help making the decision largely understandable and consensual, where I'm afraid that any T or L variant would significantly unplease large sets of maintainers. Thanks for considering, cheers, Didier signature.asc Description: This is a digitally signed message part.
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
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). Actual support for things beyond that minimum will require people who care about various init systems to step up and implement it. * 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. 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. 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? -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
Colin Watson writes (Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)): 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). Actual support for things beyond that minimum will require people who care about various init systems to step up and implement it. Precisely. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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.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
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
Didier 'OdyX' Raboud dixit: Now, I think there is currently a shared agreement in Debian that all Debian packages (unless there's a good reason) should run on sysvinit + Linux + amd64 , support outside that is best-effort Eh, no! Debian is the universal OS, and it has quite a number of release architectures. And even then, including support for everything else is still strongly encouraged. bye, //mirabilos -- 13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good guy. But he's always right! In every fsckin' situation, he's right. Even with his deeply perverted taste in software and borked ambition towards broken OSes - in the end, he's damn right about it :(! […] works in mksh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Thu, Feb 06, 2014 at 01:30:25PM +0100, Didier 'OdyX' Raboud wrote: 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: So Didier recently forwarded this to the secretary, saying: I've mailed Message-ID 1997214.E2693zAoXp@gyllingar to the init system bug, but forgot to CC you for a more binding advice on the constitutionality of L. I'm therefore hereby writing to you explicitely; my original message is attached. Don't hesitate to prove me wrong publically, I'm only interested in having a constitutionally sane decision out, rather sooner than later. I have also asked them under which power they decide things. This makes things so much clearer for everybody. The text from the last vote said: == dependencies rider version L (Loose coupling) == Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. I'm guessing that under you're asking for the interpretation of this in 6.1.1: | In each case the usual maintainer of the relevant software or | documentation makes decisions initially And think that because the policy maintainers didn't try to make any decision yet, the ctte can't make that decisions? I can certainly understand that that is one way of looking at it. I'm not yet sure about this and would like to receive some input. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Thu, Feb 06, 2014 at 08:38:25PM +0100, Kurt Roeckx wrote: I'm guessing that under you're asking for the interpretation of this in 6.1.1: | In each case the usual maintainer of the relevant software or | documentation makes decisions initially And think that because the policy maintainers didn't try to make any decision yet, the ctte can't make that decisions? I can certainly understand that that is one way of looking at it. I'm not yet sure about this and would like to receive some input. I'm currently of the opinion that gnome made an initial decisions and as reaction to that they are setting policy and that this will be allowed under 6.1.1. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
Kurt Roeckx writes (Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)): I'm currently of the opinion that gnome made an initial decisions and as reaction to that they are setting policy and that this will be allowed under 6.1.1. Yes, the T-vs-L thing is setting policy. (Although we're leaving the exact text of policy up to the policy editors.) Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote: ... Now, I think there is currently a shared agreement in Debian that all Debian packages (unless there's a good reason) should run on sysvinit + Linux + amd64 , support outside that is best-effort sysvinit support was mandated indirectly due to it being the one and only init system used by Debian. But contrary to what you are saying, there is not one main Debian port that matters and all the others are just best effort. Now, I think this default init decision's purpose is to change the above agreement by replacing the syslinux in the above sentence by one of the contenders. Both the T and L riders purposedly don't say anything about the default init, and I think that's wrong: ... You might think that is wrong, but (like basically all possibilities) this has already been discussed here and none of the members of the TC seems to favor a must not require any init other than the default init so it didn't even make it to the TC ballot. In practice, L means that the old status quo that all packages have to work under sysvinit stays. And that also has benefits, e.g. it reduces the hassle for downstream distributions who use an init system other than the one Debian uses as default. There is not any right solution everyone could agree on, and after months of discussions it is extremely unlikely that someone expressing his opinion now could change the vote of any member of the TC. Thanks for considering, cheers, Didier cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
