Bug#727708: loose ends for init system decision
]] Russ Allbery
> Given that, I don't believe a Technical Committee choice of a default init
> system is going to make either the systemd or the upstart maintainers want
> to stop maintaining their packages.
Given what you're basically deciding between is «upstart + castrated
systemd» or «systemd» and I think I've pretty clearly expressed my
thoughts on splitting up systemd, I don't know where that conclusion
comes from. Were you to choose upstart, I'd be seriously thinking about
stopping maintaining systemd. (This is meant as a data point, not as a
threat or anything like that.) My ideas for the package align pretty
well with upstream (which I'm a sometimes-active part of) where the
different services are free to assume that they run with systemd as pid
1. Continously porting new upstream versions to an environment
unsupported by upstream is not what I consider reasonable or fun. I'm
speaking for myself here, not the other systemd maintainers.
In addition, as per my other message, were you to choose upstart as a
default, I'd be inclined to remove the init functionality from systemd.
I think trying to support multiple init systems is crazy and a recipe
for disaster and I don't want to do that. (Doing it as part of a
transition is a necessary pain, that much I can agree with, but ongoing?
No thanks.)
> 6. Debian's non-Linux ports should either use the same init system as
> Debian's Linux ports or agree on an init system that they're both going
> to use. The porting work is going to be hard enough without the ports
> going in different directions on which secondary init system they want
> to use. I prefer to leave it up to the porters to decide which init
> system to choose, but I do think OpenRC would be a strong contender.
I think allowing them to use a compatible init system should be ok too,
if somebody wants to do that.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: