Re: Integration with systemd
On Wed, Oct 30, 2019 at 01:51:07PM -0700, Josh Triplett wrote:
> > So mostly, this isn't going to be up to us. It's going to be up to
> > the upstream. Eventually, for each package where upstream has chosen
> > to use these technologies, our choice will be (a) to drop the package
> > from Debian, (b) add backwards compatibility support for systems which
> > haven't drunk the systemd kool-aid, or (c) mark that the package only
> > works for systemd.
> >
> > I think we've mostly accepted that we can't force package maintainers
> > to do (b), and for many packages, such as for example GNOME, (a) will
> > be a non-starter, which means we're left with (c).
>
> There's a big difference between "we've mostly accepted that we can't do
> otherwise" and "people can safely rely on not getting flamed". The point
> of my mail was the latter.
So I believe that if we believe the former, then we *have* to say that
it's not fair that Debian Maintainers get flamed, and that it is
**not** an obligation of the Debian Maintainer to "fix" what might be
perceived as a regression.
If we need to have a GR, or a TC ruling, to make a statement in Debian
Policy which to me is self-evident, then so be it. But when we don't
have a choice, we don't have a choice, and it's not fair to make life
unfun for Debian Maintainres who can't dictate the choices of upstream.
> It's not just about upstream. Many of the capabilities of systemd would
> be useful in Debian-native components and packaging. And given that, as
> you observed, upstream can already use such capabilities, then it
> doesn't make sense to stop Debian developers from using those
> capabilities, where doing so provides a benefit.
Perhaps; although if there aren't yet significant number of critical
upstream packages using some particular new systemd functionality,
deliberlately using that feature and completely ruling out some
alternative init system seems to me to be different. I guess the
difference is one of an act of comission versus act of omission.
And if we do this in core Debian infrastructure, such as say, in dpkg,
then that's *really* different. That's completely ruling out
sysvinit. And that to me is different from something like "GNOME no
longer works on sysvinit" (until someone enhances elogind). In that
case, it's the GNOME Project which screwed over sysvinit, not Debian
--- and we're just saying that it's not the GNOME Debian packaging
team which is obligated to fix things up.
But the dpkg maintainer making a change which screws over sysvinit
*feels* different, both in that it affects all Debian installations,
versus just the ones using a particular GUI, and whether it was Debian
or GNOME that made that particular decision.
Let me be clear, my personal opinion is that Lennart, and the
acceptance of systemd by the vast majority of the major distributions,
means that eventually, most upstreams will be using more and more
systemd features, and people who like sysvinit should just get over
it. But whether we should accelerate that transition, or let it
happen at a more natural pace, is something which IMHO, needs to be
handled on a case by case basis. Exactly how much of a win do we get
if we use a particular systemd feature in core Debian packaging? How
hard is it to emulate that for non-systemd systems? I don't think
that decision can be made in the abstract, unless we as an entire
project want to vote to deliberately, and with malice aforethought,
kill off sysvinit support in Debian.
Is it really worth it to make that choice now, as opposed to letting
other upstream projects make that choice for the entire Linux
ecosystem naturally?
And some good might come from making this transition more slowly;
maybe it will encourage people who have that sysvinit itch to scratch
to gradually separate out some of systemd's functionality, and
implement it in modules that can be used without pulling in all of
systemd. I personally don't have that itch; but perhaps others do.
Cheers,
- Ted
Reply to: