On Sat, Jan 25, 2014 at 08:20:35PM +0900, Charles Plessy wrote: > Le Thu, Jan 23, 2014 at 04:14:41AM +0100, Wouter Verhelst a écrit : > > On Thu, Jan 23, 2014 at 09:58:14AM +0900, Charles Plessy wrote: > > > In that case, I think that the project should decide via using this or that > > > system (“vote with the feet”). For the packages where init scripts are a > > > limitation, just depend on systemd, upstart, openrc, or combinations of them, > > > and if and only if it is not possible to install Debian because pairs of core > > > packages depend on different single init systems, let's vote. > > > > So, let me get this straight. > > Hi Wouter, > > OK, let's be straight :) > > > You're saying "let's do nothing until the entire system breaks because > > of a component that nobody really cares about, so that we can _then_ try > > to start a procedure which will take weeks (if not months) to maybe > > unbreak it, leaving the system in an utterly broken state in the > > meantime?" > > What I am saying is: > > Let's allow the Debian system to evolve freely: the result will not be > breakage, but systemd as a de facto default. This argument has been brought up before (indeed, even by me), and has been debunked by several people. There are several problems with that approach for the choice of init system: First, a change of MTA, FTP server, or browser produces a user-visible change in an area that most users will care about. An init system does not--and note the "most" in the previous sentence. Second, it is possible to define the interface which an MTA, FTP server, or web server should provide to the rest of the system (e.g., "serve files in this directory by default", or "send mails to remote users if passed to the sendmail binary") without going into too much technical detail on how exactly the MTA, FTP daemon, or web server needs to do so, and also without sacrificing features that we might want. The same is not true for init systems. For instance, while we could just declare that all packages need to provide initscripts (which then means that even sysv-rc could still be used), that really is just the status quo, and we might as well not bother. I am personally convinced that we *do* need a better init system. I don't actually care _which_ init system that is, and am contend to leave that decision to the people who do. But we should not retain the status quo. If you think systemd will become the de facto default, then why not just throw out the years of bickering and bikeshedding and just decide that _now_? We should have made a decision on this subject years ago. The "debate" is reducing the quality of our mailing lists, is holding the entire project hostage, and we're *still* no closer to an answer. Even the TC seems to be having difficulties reaching a decision. So, let me propose the following amendment, then: ----- If this option wins, the project secretary, in the presence of at least two other Debian Developers, will roll a dice. If the dice comes at rest with 1 or 2 facing up, systemd will become the default init system for Debian. If the dice comes at rest with 3 or 4 facing up, upstart will become the default init system for Debian. If the dice comes at rest with 5 or 6 facing up, openrc will become the default init system for Debian. ----- I am looking for seconds. And no, that's not a joke; at this stage the debate is essentially deadlocked, and I am doubtful that the debate will *ever* reach a conclusion which will be the best on a technical and/or political level. All available options feature some things that the others don't, all have downsides, and none of the available options will ever be a perfect solution. We could discuss this ad infinitum and end up with a non-solution, or we could just bite the bullet and make a decision. At this point, I think any decision is better than no decision, even if that "decision" is the throw of a dice. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/
Attachment:
signature.asc
Description: Digital signature