These discussions are best served with stark clarity and accuracy, otherwise it becomes too difficult to reach anything resembling consensus. So let's try for that:
** KDE SC?
This is not about "KDE SC". It is about Plasma 2, and this limits the scope considerably.
Firstly, it means we're talking about the KDE Frameworks 5 era in which the libraries are not shipped in one big chunk as they are in KDE SC 4.x. As a result, we would expect installing Krita would not
pull in a systemd dependency. It probably should also mean that only when installing a Plasma workspace (e.g. Desktop) that you'd get such a dependency.
** Added dependencies
There are a lots of hard dependencies in Plasma Desktop right now. Want integrated networking config? You get to use Network Manager. Bluetooth? BlueZ. Start a graphical session at all? x.org
. Of course, it also all relies on Qt.
In some of these cases there are no alternatives (e.g. BlueZ); there are for others however. There are alternatives to Network Manager, for instance. What happened there? Well, nobody
stepped up to support anything other than Network Manager, even though it was possible, so now the Network plasmoid only supports Network Manager. This could still happen now thanks to the modular nature of Plasma but it hasn't. Well, sort of: we wrote a small Plasma widget for conman that was used with the first couple of versions of Plasma Active on Mer OS .. until Mer OS switched to Newtork Manager removing our need for it.
How about Qt? Well, we needed to choose something, and ~15 years ago someone did. Qt it was, and Qt it remains.
So hard dependencies are not in and of themselves horrible. Complaining about dependencies is complaining about capabilities. With no dependencies we can have a small and utterly featureless system, but we don't want that. This isn't 1990 when disk was expensive and CPUs horribly constrained.
To make a good selection, we need to be reasonable and ask ourselves a few questions:
* Can we reasonably make the support optional?
* Should we use an in-house solution or outsource it?
* Can we reasonably support more than one option from the perspective of technical design?
* Is there manpower available to implement and maintain support for more than one?
So let's start with a definition of what the need is:
A Plasma workspace needs a way to start different processes as fast as possible while ensuring that dependencies between them are met. Sounds like an init system right? :)
Additionally, Plasma workspace has several processes that must be long-running and be guaranteed to restart if something goes wrong (crashes).
Turns out with a well designed init system, you can get the second need for free.
So .. let's take the questions in light of those needs:
* Can we reasonably make support for this optional?
No: we need to start sessions. So there will be an init system somewhere
Currently it is in the kde-workspace module. It takes the form of a shell script (!) that's been in constant use for a long, long time and while it works it is neither fast nor does it have any capacity to order the startup beyond the fixed order of things in the script and the semi-random nature of xdg autostart and session restoration.
We have another one that we built for Plasma Active and it does basic dependency management. (I suppose very few people know that we have two different init systems for Plasma Workspaces?)
So it isn't optional.
* In-house or outsourced?
Our experience with session starting is that it is non-trivial. If there is a solution that already works, that would be fantastic, saving both developers time and users from dealing with bugs.
Moreover, using an external system used by more than just us opens doors for better system integration.
Right now there is only one
target platform that has done any real work in this area: Linux. So guess who gets to call the shots there? :)
Within the Linux world, those that have moved away from shell-scripts-in-etc init systems have gone in two directions: upstart and systemd. Which brings us to:
* Can we support more than one?
It should absolutely be possible. This is what I alluded to in my first posting. This is a feature set for which all the implementation should be kept in one central location rather than sprinkled across the entire codebase. That means it would be replaceable.
Furthermore, I imagine Plasma will keep the startkde shell script around for legacy purposes offering two ways to run the system: an old and less featureful/reliable mechanism, and a better system.
If the better system becomes overwhelmingly used by our users then perhaps startkde will die. I would hope that Plasma Workspaces would still keep the session management code centralized to allow for future adaptation to changes in the underlying system(s) used. This is one reason why having something like Solid, even if it has only one backend on a given system, is so useful.
* Is there manpower to support more than one?
No. Not because there couldn't be in theory, but because there isn't in practice. The proof is that nobody has stepped up outside the core group, and even that interest has been sparse. It's been ~1 year since first attempts at this started, and ~2 for the Plasma Active init system (which was built and then put into maintenance almost immediately). There just isn't the interest.
So we have to prioritize. Obviously, we should satisfy the majority of our user's needs first and work on minority group needs later (or wait for people within them to step up and do the work).
The majority of our users are either on sysv init style systems (startkde for them, then) or systemd systems. Red Hat, SUSE, Arch and others have moved to systemd and this seems to be picking up. For Plasma Active, we focus on Mer OS which happens to also have moved to systemd. Note that Red Hat used to use upstart, but moved away from it due to limitations, creating systemd in the process.
Upstart is used by Ubuntu and some of their derivatives. The vast majority of those provide environments other than Plasma to their users. Ubuntu itself is becoming harder and harder to target as they maneuver their stack further away from other offerings (c.f. Mir). The primary Ubuntu based OS's I know of that people use KDE with are Kubuntu and Linux Mint KDE.
Those are the difficult ones, indeed. Should Debian move to systemd, then perhaps it becomes easier for Kubuntu.
In any case, there is a schism here and we need to prioritize. systemd will hit more of our user base on more systems than upstart would, and startkde can fill the needs for the non-systemd systems.
When we add to this that systemd has relevant features and integration upstart does not currently provide, the decision becomes more evident. In fact, upstart tends to pull in features from systemd .. so picking upstart would mean picking both elements of systemd and upstart. Those worried about dependencies should be able to do the math there.
So lacking manpower, the answer is self-evident imho: systemd, with a shell script (starkde) fallback.
If done "right", the init management will be centralized and a hardworking, enthusiastic person could replace that component with one that uses upstart. Just like someone could create an implementation for a network stack other than Network Manager.
The rest of the discussion about politics, dependencies, OS support, etc. are moot compared to the above imho.