[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)

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 

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 

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 

    "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,


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

Reply to: