Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Just for the record (and I might be wrong with this information,
because I don't have it from a "official" Gentoo source):
I heard from a Gentoo dev that they will switch from OpenRC to
systemd, and find the possibility very funny that Gentoo switches to
systemd from OpenRC and Debian switches to OpenRC from init. :-)
So, it looks like Gentoo devs see value in systemd so they're consider
dropping OpenRC for systemd.
About the general issue: I think whoever wants to work on stuff should
be able to work on it, so having OpenRC packages is not really a bad
thing. So, if someone wants to do it, just do it :-)
For making OpenRC default I have an other opinion: I consider systemd
superior and I think making OpenRC default is just the wrong way. And
I very well think we can fully support systemd and kfreebsd. I already
build my packages with systemd(-logind) support in experimental and
use ConsoleKit for non-Linux ports, which works exttremely well.
With the new init-script-from-systemd generator, using sysvinit on
non-Linux systems should also be possible, although the non-Linux
porters might need to write some additional initscripts for more
complicated daemons, but this should be possible to do. (It's an
effort, sure, but it's worth it and a good compromise)
So, I don't really see any problem anymore with systemd support. And I
also have to agree with many points Josselin made (although I usually
disagree with him quite often) - Choice in core infrastructure is not
worth the effort just to have a choice. (This argument doesn't count
for desktop components, of course) - Instead, we at Debian should
provide a technically excellent OS, not a thing with many
Just my 2ct.
2012/9/2 Josselin Mouette <email@example.com>:
> Le samedi 01 septembre 2012 à 12:28 +0800, Thomas Goirand a écrit :
>> It goes from a more manageable code (for some parts, the same
>> feature as in systemd, but with a code that is 5 times smaller),
> Code size is a compelling argument only with the same set of features.
> Which is not the case.
>> to the fact that it may work with something else than Linux,
>> or the fact that it supports also mdev.
> Supporting mdev is not a feature. Please tell us about what features you
> intend to bring with that.
> Josselin Mouette /\./\
> « Sans puissance, la maîtrise n'est rien. »
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
> Archive: 1346578639.12827.2.camel@tomoe">http://lists.debian.org/1346578639.12827.2.camel@tomoe