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 <vor...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52692a8a.9010...@debian.org
