Re: let's split the systemd binary package
On 10/24/2013 04:51 PM, Tollef Fog Heen wrote:
> ]] 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.
We've been reading again and again from systemd supporters that it's
modular, and that we can use only a subset of it if we like. Now, we're
reading a very different thing: that it's modular *but* we need to
re-implement every bit of it so that the modularity becomes effective.
That's a very different picture... :(
> 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 get your point about the cost, and I agree with you that there is one
which we should keep in mind in this discussion. But IMO, your example
isn't working. It is correct that, currently, can't swap the coreutils
for busybox, or switch to another implementation of the libc. But we are
still allowed to choose between Linux, kFreeBSD, Hurd. And clang and GCC
can also be swapped (this last one is even a proposed release goal!). I
suppose you will agree that a kernel and an ISO C compiler are very
complex components.
Also, things like the the boot loader (syslinux, lilo, grub...), the GUI
login (kdm, gdm, xdm...), or the system logger (with even some remote
server syslogger available), have all for a long time, been
interchangeable very easily with just an apt-get install. It used to be
very simple and easy, and it should continue this way.
We're now being told that we wont be able to choose *anymore*. This last
word is the most important of them all: anymore. I (and AFAICT others
too) see this as a regression (and this has absolutely nothing to do
with the quality of the components of Systemd), and a possible way to be
locked-in.
Upstream authors are working in a way that either imposes some packaging
work to keep the modularity we used to have, or we're locked-in. This is
what made others (this means: not me) say that these upstream authors
have an "agenda", using this fact to impose all components of Systemd.
Hopeful this is wrong, and it must be the case that they simply just
don't care, and believe that we should adopt all of these components
anyway, so it doesn't make sense to do things "the old way" (understand:
with anything that Systemd doesn't re-implement), because they think
that's the only way to have the features they want/need, and that
systemd is just better, so why should one even think about using
something else? I really don't think there's anything malicious or "an
agenda" here, to take over the Unix world, but that's effectively what
is (unfortunately) proposed.
At the end, if in Debian, there are ways so that we have all components
of systemd and Gnome work well together *and* retain the modularity we
used to have, I think we should go for it. And yes, to the extend of
feasibility, this is IMO up to the systemd and Gnome maintainers to not
introduce a regression where one (even if it's at the cost of loosing
some upstream functionality) doesn't loose the possibility to choose
components running on his system. Since there's a Ubuntu patch, why not?
Or is there more to it? The more the answer is "yes, it's becoming a lot
more complex than this", then the more we'd be locked-in.
Thomas Goirand (zigo)
Reply to: