On Thu, Oct 31, 2019 at 01:44:58PM +0000, Ian Jackson wrote: > Martin Steigerwald writes ("Re: Integration with systemd"): > > As to this, I did not yet see that the migration of elogind to testing > > has been accepted. > > Yes. > > I find these conversations draining, exhausting, awful. I am sure > that most people who are sceptical of systemd agree. The constant > negging and doom-saying is very unpleasant. > > And, are we going to continue to wear people down with awful threads > like this one, where a parade of doomsayers tell us we can't have what > we want *even though it already exists and is maintained* ?
That's true SO FAR. The fact remains that systemd has *tons* and *tons* of new features which to date, aren't yet getting used in huge numbers of open source software packages or in Debian packaging --- YET. If we do need to have a GR, we need to be very careful how the choices are worded. We should be clear whether we are giving carte blanche for Debian developers to use every possible systemd feature under the sun, whether or not there are non-systemd emulation possibilities yet. Or whether we are simply saying that we are not mandating that Debain Maintainers don't have to do extra work to support non-systemd systems, but they shouldn't be actively working to make things. Let's take e2fsprogs for example. I had applied a patch which had a cron script alternative on top of the timer unit file. It turns out the cron script was buggy, and it took multiple tries before we got it right --- because I don't maintain a test system with sysvinit to test it. So I applied patches, but I was *not* doing my own testing before releasing updates with the cron support. I'd call that "best efforts" support. The GR should make clear whether or not what I did was sufficient --- I took patches and attempted bug fixes to support sysvinit --- or whether I should have been doing more explicit testing for sysvinit. The GR should also make clear whether it would be a good thing if I, as the Debian Maintainer, were to deliberately use some esoteric systemd feature for which there is not non-systemd alternative in a package's packaging scripts. (I wouldn't do such a thing, in general, since I personally a good programmer should do things portably, and using an esoteric systemd feature is *not* good programming practice. But it's clear that others, like perhaps Josh Triplett, feel differently. And I don't feel that I should necessarily be imposing my personal beliefs on everyone.) Again, look at Josh's list of all of the random esoteric systemd features that people *could* be using. I think you're painting a far too optismistic picture that there will always be enough programmer interest to keep up with systemd's many and varied new features. - Ted