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

Bug#727708: Call for votes on init system resolution

Quoting: Steve Langasek <vorlon@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.)

Reply to: