If xorg will depend on systemd like the article claims, do you have any suggestions how to run my XFCE who *cannot* use systemd? First udev, then GNOME now potensially xorg. Where will it stop?
oh.. i will have to write my own xorg implementation too. ok will do so as sson as I am done with my udev, consolekit, polkit and logind implementations.
I am not suprised that people (who have other values than systemd dev) get worried.
There are only two ways of dealing with some software A that is not compatible with a newer version of some software B (and it happens all the time): either you change A, or you don't update B, and A becomes "legacy".
Code:$ emerge -pv xfce4-session These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] xfce-base/xfce4-session-4.10.1 USE="systemd udev xscreensaver -debug" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB
Some of these dependancies make sense, some do not, and then there are the undeclared dependancies. I will not present examples of each.
Mountall uses Plymouth to talk to the user, so does Cryptsetup in Ubuntu. I don't know a whole lot about mountall, but I know a lot about cryptsetup and have written my own plymouth theme (greentree). To allow interaction of mountall or cryptsetup with Plymouth not installed as opposed to splash not shown would require writing extra code into the binary or scripts. I know this because I have my own program for starting encrypted disks, and I too used the Plymouth commands for handling passphrases, meaning my package also depends on Plymouth. I added echo alongside plymouth --display-message so the output is readable on console. Plymouth works fine for accepting output from console with the splash not showing. On the other hand, to accept passphrases with or without Plymouth would have required checking to see if Plymouth is installed (or if it is running), then case-switching the input mode between plymouth --ask-for-password and something else. The code would grow fast as I tried to include more options, and each possible case would have to be tested. Thus it makes sense to depend on plymouth rather than attempt to support both cases. A splash screen need not be running and no theme for one need even be installed.
Now I will discuss a false dependancy: Cinnamon and Pulseaudio. If you run Cinnamon with pulseaudio removed (or the binaries deleted/made not executable), the only things that don't work are the cinnamon volume control and cinnamon sounds. Those sounds depend for some reason on canberra-pulseaudio, but the DE as a whole does NOT need these sounds to be a good, functional desktop. Cinnamon-control-center depends on Pulseaudio, presumably to be able to control Pulseaudio. My guess is that with Cinnamon using Pulseaudio for sound events, plus the volume control applet being presumably a port of GNOME's PA-only volume control, they decided the easy way was to make the whole deal depend on Pulseaudio. Since I do not use Pulseaudio, I ended up making a dummy "pulseaudio-dummy" package that "provides" pulseaudio but is an empty package. I use Volti for a volume control, probably should list that as a dependancy. Cinnamon could split out sound into a "cinnamon-sounds" package and then depend on either PA or Volti, but that would be extra work for a small number of users. That being so, I fixed this myself for my own use.
I remove Pulseaudio because I need the utter maximum performance when dealing with cranky AVCHD files in video editing. Not having it on my netbook is a nusiance as that machine lacks hardware audio mixing, yet it also doesn't have enough CPU to run pulseaudio and decode 720P H264 video at the same time and video is the priority. I use JACK to allow mono sountracks to be played on it.
Making dummy packages to counter these sort of dependancies works so long as the package you are trying to get to install does not require the program you are bypassing simply to run. For instance, if Cinnamon-session waited for Pulseaudio to come up, then a custom session would become needed to run a Cinnamon desktop without Pulseaudio. Its package would need to "provide" cinnamon-session if you don't want to have two sessions, only one of which works, installed.
The flip side of this coin is undeclared dependancies, where a package installs just fine but won't run until another package is installed. Again there is an example in Cinnamon: Cinnamon recommends cinnamon-screensaver, does not depend on it. Beginning at about version 2.05, the cinnamon-session would not start if the screensaver was not installed, even though Cinnamon could be run by changing into it from another session (at least those that don't either respawn or kill X). Lots of people do not set the package manager to treat recommends as dependancies to keep out packages they do not use. The only reason I was ever able to find that one was that it is recorded in .xsession-errors.
The Cinnamon devs have a hell of a lot on their plate, having to revert all those tablet-style changes in GNOME that users of traditional desktops don't want, yet keep up with the backend side of everything. I'll take a little dependency hacking over perfect installer settings but a DE that is crashy from inadequate development and testing any time. I am quite happy with Cinnamon's performance on any machine that can handle gnome-shell.