[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: let's split the systemd binary package

]] Steve Langasek 

> 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'm not sure how you get from «some component wants bits of what an init
system provides» to «let's disassemble the various components of the
init system and put the maintenance burden on the maintainers».

If GNOME decides they want the DBus interfaces from systemd, that does
not put any obligation on systemd or the systemd maintainers to split
those bits of functionality out of systemd.

Let me do a small detour here, because I think this is at the core of
the discussion: We're in this building an operating system, together. We
discuss, argue and bicker a lot, but the goal is to make a great, free
OS.  While some flexibility and choice is necessary, choice has a
cost. That cost comes in forms of more and harder maintenance, increased
complexity and more bugs.  Sometimes, we choose to take that cost
because we collectively decide that the benefits are worth it.  The
mail-transfer-agent is probably the best example here.  In other cases,
we don't allow choice.  We don't compile Debian for multiple libcs.  We
don't allow you to trivially swap out coreutils for busybox.  In this
particular case however, it's not even about switching out complete
components.  It's about taking some components out of one package and
making them work outside that context.

I'm arguing for that systemd is a complete package.  You can't just take
one part of it and expect it to work, at least not without throwing
engineering time at it as well.  However, it usually interfaces with the
rest of the world through well-defined interfaces.  If you believe that
the components implementing those interfaces should be swappable, you're
free to implement your own logind-a-like and we'll be happy to work with
you to make that work well and ensure the interfaces are stable.  Maybe
this will even make people on FreeBSD happier since they can then get
some of the benefits.  Alternatively, if somebody shows up and shows
long-term commitment to making logind work without systemd as init, gets
upstream buy-in and commits to ensuring that configuration works
long-term, we can talk.  What I'm not ok with it is having anybody
dictate that I should fork an upstream package against what I believe is
their good advice.

Having patches from Ubuntu is all nice and good, but as none of the
Debian maintainers are running in that configuration, nor is interested
in it, I think providing the appearance that we support or recommend
that configuration is dishonest and doing our users a disservice.

Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Reply to: