Hi, On Wed, Oct 30, 2019 at 05:17:57PM -0700, Russ Allbery wrote:
> 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. >From an integration point of view we need to make sure that software that is installed also works, and I have little trouble when packages declare an explicit dependency on systemd running as pid 1. They need to declare a dependency nonetheless, because init systems have never been Essential, and also because the dependency likely needs a minimum version. There is no point for Debian in taking a stance against using systemd features, because upstreams will do that anyway, and we neither have the manpower as a volunteer project to provide alternatives, nor as a distribution the duty to. Our goal is to provide packages that allow you to put together a working system. If upstream decides that their software will only work with systemd, we make note of that and move on. We already have enough work to deal with the fallout in our own infrastructure -- I've mentioned earlier[1] that libgtk-3-0 pulls in systemd-sysv, so autobuilders will install it quite often, and we need to make sure this doesn't break anything. However, a lot of our software comes from the BSD world and will never fully switch to systemd, and that software is often used in server contexts by people who know exactly what they are doing. I don't see why we shouldn't support these people anymore, especially as they are the ones who cannot be served equally well by other distributions. > > 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. Not quite, I think. The goal is to allow people to omit complexity from features they will not use. My laptop will never automount USB sticks, so the code path for that doesn't even need to exist. My web server will die in a horrible way if someone finds a buffer overflow in the SSL code, and it will stay down until I can manually investigate, there is no code path that will give the attacker another chance to get the offset right. The freedom to configure a system without things I do not want is one of the main reasons that made me switch over from Windows to Debian, a bit more than twenty years ago. > 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. That is work we have to do regardless of whether we want to support alternatives or not, but in the simple case we just list what is supported by the systemd version we have decided to ship in the last stable release, so we can have backport packages with reasonable effort. Infrastructure I'd like to see is - dh_systemd generating a versioned dependency for the unit files given - apt being able to blacklist packages and hide packages that depend on those This cuts both ways: for packages with optional systemd integration, I'd expect "sysvinit" variants to pop up, and we don't want users running systemd to accidentally install these if a tighter integrated variant is available. > 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." No, and that's not our job. There are a lot of people out there building non-systemd systems. We do what we've always done, packaging them to the best of our ability. Simon [1] https://lists.debian.org/debian-devel/2019/08/msg00278.html
