Josh Triplett <j...@joshtriplett.org> writes: > Part of the problem is that the people interested in sysvinit don't tend > to care about those features and often argue that others shouldn't care > either, and the people interested in those features don't tend to care > about sysvinit. It's difficult to motivate people to work on > alternatives for a system they already have and prefer.
*This* is the thing that I feel we need to tackle head-on. Because there are a lot of reasons to care about those features, but possibly more convincingly, as Ted points out, *upstreams* care about those features and are not going to stop caring about those features just because Debian packagers do not. Sure, some systemd features are only marginally better than what came before (I admit to not being much of a fan of timer units, for instance). But this will vary by person. For example, as a security person, I care a *lot* about namespacing, capability reduction, and seccomp filters, and I want to use those features in my packages to make the default configuration more secure. Other people are going to care a lot about D-Bus integration, and some upstreams are going to fully embrace socket activation (which, again, I'll point out is one of the easiest features of systemd to implement outside of systemd; implementations of the same idea predated systemd by many years) and just not support any way of spawning their service that doesn't satisfy the systemd socket activation API. One can individually say that one doesn't care about those features, but we just cannot say Debian as a whole should not care about those features. It doesn't work. We have to take an affirmative stance on what Debian is going to do with software that does care about and use those features; whether we're committing to porting it, whether we're going to kick it out of the archive (that seems highly unlikely to be viable), whether we're going to say that software with a hard dependency on systemd features is allowed to only work on systems running systemd, or some other alternative. But saying "no one should care about those features" isn't a choice and isn't a path forward and we can't stop there as a project. > That's leaving aside that a reimplementation of systemd's features will > tend towards becoming systemd, and we have one of those already. What is > the actual goal? The actual goal is to allow for different ecosystems that provide the same features while embracing different implementation philosophies. I know that you don't think this is a valuable goal; please let's not have that argument yet again. I'm sure you realize by now that some people simply do not agree with you and do not find your arguments convincing. > It seems evident based on the history of such efforts that there is > *not* sufficient people/interest/motivation to reimplement the majority > of systemd features, let alone doing so in a way that meets the > additional constraints imposed on such solutions. I don't think the question has yet been forced. Up through buster, one has been able to mostly run Debian on sysvinit without doing this work, with some pain and some gaps and some issues. I think we're coming up to a point where this issue will be forced because both packaging practices and upstreams are diverging away from sysvinit support. I think there are two questions here: 1. Do we as a project want to do the work to leave open the possibility that such resources will materialize? This means doing things like defining a subset of systemd unit features that packages can rely on, and requiring (some? all?) packages not use features outside of that set. "No" is a possible answer here, but this is a political question with significant consequences, and I think it should be decided democratically. 2. Are we as a project *capable* of producing a non-systemd alternative that's viable? If the answer to question 1 is "no," then this question doesn't arise. But it's entirely possible that the answer to question 1 is "yes" but the answer to this question is still "no." -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>