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

Reply via email to