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. If some parts of the system become mutually exclusive, I do not see it as problematic. We do not support the co-installation of some mail or FTP servers packages even though in theory one can configure them to listen on different ports; if tomorrow one desktop manager depends on upstart and another on systemd, then the solution is to call this unsupported as well. I would also argue the same if it were web browsers. I would call a system broken if it would not be possible to do anything useful with any of the init systems. I do not see how this could happen. First, these init systems are developed and tested on computers that run them, such as Fedora, Ubuntu and Gentoo, which shows that there is no critical missing piece in one or the other system in the context where they are intended for. Second, at least systemd runs fine on Debian currently, and to my knowledge, there are no core components that are likely to drop systemd support in the near future. Then, there is the fear that because systemd or upstart is much easier to support than our current init system, the non-Linux architectures that can not run them will dissapear because init scripts will be dropped massively. To me it is a total overstatement. What is at stakes is whether these ports will benefit as much as before from the work on mainstream systems such as Linux on amd64. The answer with is “no”, unless we enforce a default with this goal in mind, that will cost to others what it gains to the non-Linux architectures. But that “no” does not make these projects impossible. At worse, it will force them to focus on their userbase instead of working on total coverage of the Debian package supermaket, and I think is would actually be a good change (please do not waste your time sending patches to leaf packages until you know that somebody is actually planning to use them on your port). Lastly, there is the political part. Should we boycott systemd or upstart ? Should we make choices that in practice mean to show the door to our GNOME team ? Should we push even more our contributors to participate to the porting on specialised architectures ? Let's releive the technical comittee from the pressure to step in that field. The best reaction to these questions is to ignore them. So definitely, thanks Steve and the sysinit maintainers for making transition between init systems easier; with this I do not think that we need a decision on a default system anymore. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140125112035.gl24...@falafel.plessy.net