Re: let's split the systemd binary package [Was, Re: systemd effectively mandatory now due to GNOME]
Steve Langasek wrote:
> On Thu, Oct 24, 2013 at 02:21:25AM +0200, Matthias Klumpp wrote:
> > 2013/10/24 Steve Langasek <vorlon@debian.org>:
> > > [...]
> > >> If Gnome depends on gnome-settings-daemon, which now depends on systemd,
> > >> this might be a worrying trend, as non-Linux kernels don't support systemd.
>
> > > Well, that's one more reason the init system and the dbus services should be
> > > separated out in the packaging.
> > Some of the services consume functions and features provided by
> > systemd (the init system).
>
> Which is exactly the kind of embrace-and-extend that Debian should not
> tolerate having foisted on them in the default desktop by an upstream
> pushing an agenda.
I think the agenda here is mostly "make things work", and it's less
"embrace-and-extend" than "create new things". If Debian "shouldn't
tolerate" that, then what's the alternative? Tell upstream that nothing
must change? Or that it's their responsibility to implement everything
new at least twice, with another version for Upstart just so that Ubuntu
doesn't need to admit making a mistake with that and deal with a
transition to a better system?
> > So splitting it out is not an easy task. Ubuntu manages to do that by
> > heavily patching systemd and their own upstart to support a systemd-less
> > system.
>
> So first of all, how hard it is to split is irrelevant. This is work that
> must be done, and Debian should not accept excuses for it not being done.
>
> Second, there's nothing hard at all about applying these patches that have
> already been written and are being used in Ubuntu. Indeed, AFAICS there's
> only one patch to the upstream code currently missing from the Debian
> package:
As I already said in my previous mail, this is not at all true for
systemd v205+. I think you'd basically need a completely separate logind
package for non-systemd systems.
And if you think this is work that "must be done", then it is YOUR
responsibility to do it. It's not the systemd maintainers'
responsibility to implement new functionality for non-systemd systems.
If you want to keep using another init system, then it's your
responsibility to do every part of the work required to ensure needed
interfaces are available on such systems. Systemd maintainers should
only need to ensure that things work well with systemd and there is a
reasonable update path to it.
Reply to: