On Wed, Oct 23, 2013 at 02:39:15PM -0700, Steve Langasek wrote: > The problem is the scope creep. It's perfectly fine for > gnome-settings-daemon to depend on the dbus services provided by systemd;
No, not even that, as long as xfce4[1] and other non-GNOME environments require gnome-settings-daemon. A bunch of us ran away from GNOME for a reason (ok, plenty of reasons). A daemon to hold *settings* for an user interface must not force a whole init system. This lies squarely in the "breaks unrelated software" land (as long as systemd does break a single thing, and with its scope it does break far more than one). > You should not get an init system installed when you install the dbus > services. This is deliberate embrace-and-extend on the part of systemd > upstream, and Debian should not tolerate it. Also, GNOME does _not_ absolutely need systemd. Proof: Ubuntu. This part of its packaging in Debian strikes me as being intentionally malicious to push an agenda. And this is not the first time, we had this with Network Manager already. > > Well, Debian is aiming for full systemd integration with Jessie, so > > there is that. > > No, please reread that mail from the release team. It is a *proposal* from > the systemd maintainers to implement full systemd support. The release team > have not said that they have endorsed this as a release goal (and frankly, I > don't expect them to do so; it's not the release team's place to decide what > Debian should use as its default init system, and to endorse such a release > goal would presuppose such a decision). There are quite a few reasons to avoid systemd like the plague it is. It's not the place to repeat those (just recall the most epic flamewar in Debian's history), so here are just two additional reasons I learned in the past ~2 months: * it is buggy. I did install a straightforward install of experimental GNOME to test if it improved even a bit, running systemd as init, and, with 2G RAM assigned to the machine, I got an OOM from one of systemd's components. Excuse me for not looking more closely but purging the machine and running away screaming: even in early stages of integration, an init system which even *can* possibly OOM is not fit for any non-toy use. * it breaks other users of cgroups. I have not tested this personally (mostly because of the above point), but if I understand it right, it takes over the whole cgroups system, requiring anything that runs on the same kernel instance to beg it via dbus to perform required actions. This might be possible to organize on a single system, but not really between multiple systems on the same kernel. Even if you run massive Rube Goldberg tricks (akin to those once needed for dbus inside a chroot), this is still doable only if you run the same version both in host and guests. And I for one heavily use vservers, which are supposed to be replaced with lxc. Not being able to run an arbitrary, possibly old[2], distribution in a guest -- or even being able to move a live system into a container, without replacing its init system, means it's a no-no for me. [1]. Fortunately not for its core functionality. [2]. It took me a lot of nudging to get the last person to finally upgrade a lenny system long after it lost security support. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- 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/20131024000946.ga26...@angband.pl
