Quoting: Steve Langasek <vor...@debian.org>
> So to make my position clear:  L does not accurately reflect what I think we
> should be doing; but given the option between L and T, I was willing to vote
> L above FD and was not willing to vote T above FD because I think T
> unambiguously sets the stage for all other init systems to wither away in
> Debian and I think it's foolish for the TC to say they are "welcome" under
> such circumstances.

Could I ask us to consider it the other way around - which is traditionally how 
packageing has worked in Debian:

Software defines its needs - so package P can have a requirement (from 
upstream) of feature A in other software that provides facilities. This is 
nothing new in Debian, from the beginning we have excelled in defining and 
resolving dependancies.

So the onus is on _other_ software providers to provide those features - and 
once those features are provided in Z as well as Y, P can depend on Y|Z OR we 
can then define a new virtual dependancy (A) can be created to facilitate 
dependancy on the feature and Y _and_ Z can then provide:A.

Right now, the L option is mandating that no package P can use feature A, 
because only Y provides it - which seems very backwards to me, surely that 
should be the impetus for Z to develop and provide the feature that P 
needs/wants? Isnt that how Open Source "competition" works?

Option "L" seems to be the commerical / patent trolling option of "you cant do 
that because my favourite software doesnt support it".

So my take is that defining option "L" destroys years of Debian policy, and I 
think the T/L debate is potentially taking Debian in a totally different 
direction where innovation can be thwarted by NIH minded packagers.

I really want us to get back to the important debate - what is going to be the 
default init system for the vast majority of Debian installs, and what is/are 
going to be the default init system(s) for the rest.

The last few weeks of circular distractons have become very damageing to the 
impetus and cohesion of the project as a whole.

Regards (I'm done - no more posts from me, I promise.)


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140208100032.gg13...@wacka.mjr.org

Reply via email to