Guest post by Starting on November 5th the Debian developers went to the polls to vote on a general resolution which would determine how init software and dependencies are handled in the venerable open source distribution. The result of the resolution will determine whether software packaged for Debian can depend on a specific implementation of init software. The init process is the first to start on Linux and UNIX operating systems and is responsible for bringing the operating system up and managing services.
The general resolution stirred up quite a bit of controversy with some developers wishing to keep software uncoupled from any specific init implementation. Others felt packages and upstream developers should be able to depend on a specific init package for the sake of simplicity or convenience. In the end, the votes were counted and it was decided no resolution would be passed addressing coupling software to init. This means, essentially, it will be up to individual packagers and upstream developers to decide whether to depend on one specific init implementation.
Confusion can reign until the next time someone asks the question!
… they resolved it, by not resolving it?
Not making a choice is in itself a choice. In this case, they resolved it by allowing developers to require systemd. In the near future, one or more vital packages will depend on systemd. The de facto result of the vote is that you will soon be unable to run a useful Debian installation without systemd. Systemd will be effectively required, even if you can theoretically get a Debian system booting without it.
Yes. The practical upshot will be similar to choosing between a GTK+ based DE or a Qt based DE. As soon as you want to install an application that requires the one you don’t run, you’re in a world of pain having to install a complex dependency tree that essentially will shadow your existing system for no good reason. Except this is worse, because only one init system can be PID 1.
I look forward to two different packages fighting over which init system they require.
Let me invite you to the wonderful world of package managers, you do not need to manually resolve dependencies anymore.
It is interesting though how you seem to be against systemd which consolidates this very aspect that you describe as a ‘world of pain’.
The functionality which systemd provides as part of it’s core tools are not bound to systemd init being pid1, that functionality can be offered by other tools, such as the functionality provided by logind, which is what GNOME requires, in turn a result of Consolekit being unmaintained for a very long time.
Recently the XFCE project said they are working on a fork of said Consolekit, hopefully this will result in a maintained alternative to logind.
Which type of package would this be ?
As for the comparison to GNOME/KDE, unlike that situation where we have two very popular desktop environments with large dependency trees which spill over on their respective applications, upstream is firmly behind systemd, and so are the largest distros, which include RHEL, Debian, Ubuntu, Fedora, SUSE, Arch etc, I’d say it’s the exact opposite of the Gnome/KDE situation:
RHEL/Fedora/Debian ships with Gnome, SUSE ships with KDE, Ubuntu ships Unity based off Gnome but is switching to being Qt/QML based, Arch ships with nothing, however they all are or will be running systemd as default.
Here’s hoping we won’t have all this drama all over again once Wayland starts replacing X .
Which doesn’t change the fact I need both systems installed. Obviously having both installed always works and they interoperate perfectly; for example not like in 14.10 where Qt applications are using the default Qt theme rather than sharing the GTK+ theme. There’ll definitely never be a similar problem with multiple applications requiring different bits of various init systems.
Which is exactly my point. Xfce will use ConsoleKit, but something else will want logind. Do you think they’ll always work perfectly with each other?
Which is different from any other dependency chain how ?
They are different toolkits with different theming engines, how could they ‘interoperate perfectly’ ?, they’d effectively be forced to develop their respective solutions in lockstep.
Again what you seem to argue for is a de facto standardisation around one solution, which is what we are actually seeing with systemd.
Who knows what the future holds, but given how the de facto standardisation around systemd as a cross-distro solution is progressing it seems less and less likely.
Well, they don’t actually work ‘with eachother’, they are alternative solutions that provide certain functionality, as long as the necessary functionality is there in both solutions then they will be easily supportable for projects needing that functionality, such as Gnome.
Of course this requires that the solutions are maintained so that they actually work, get bugfixes, are updated to support further needs, this is hopefully what the new fork of ConsoleKit achieves.
This seems to be overlooked, or intentionally kept unsaid/unwritten, a lot in these discussions.
How many of those allegedly systemd dependent programs actually depend on systemd being PID 1?
A lot of the often mentioned ones like GNOME (via logind) in fact only need systemd to be working, no matter whether it was started as init or anoher init started it.
The vote reflected that there was no need for a GR vote to begin with.
If upstream wants to target a specific solution, in this case functionality provided by systemd, then it’s the choice of the Debian package maintainers to decide if they want to provide means to run said package against alternate solutions, if they even exist.
And lack of such alternate solutions will not block the package from inclusion into Debian.
This is how it was prior to this GR, and the vote shows that this is how the Debian developers want it to stay.
Which brings us full circle, the alternatives we have in FOSS do not exist because someone mandated that they should be supported (which Ian Jackson tried to do here in this GR), but because people step up and maintain those alternatives of their own free will, that is the FREEDOM in FOSS, the code is there, pick it up and do the work.
It’s not, ‘you owe it to me to support my favoured solution, else you take away my freedom’ which is what some people have been trying to claim in this debate.
Upstream are those who create the software you are free to USE, you can certainly ask them to implement something, or take/not take a particular direction, but throwing tantrums when they disagree with you is a level of entitlement that is plain scary.
It’s like being offered a free meal and demand that it should be your particular favourite dish.
Don’t like what they serve you for free, go make your own meal (with a FORK even), or pay someone to make it exactly the way you want.
>> “Upstream are those who create the software you are free to USE, you can certainly ask them to implement something, or take/not take a particular direction, but throwing tantrums when they disagree with you is a level of entitlement that is plain scary. It’s like being offered a free meal and demand that it should be your particular favourite dish. ”
I think this line of thinking has a flaw and is overlooking (and misinterpreting) a few facts. Specifically that many people in the open source community pay for their software (or donate funds, code, artwork, bug reports, etc). Projects like Debian, Mint, Mageia, etc survive in large part from the money and other contributions their users send them. Otherwise they would have trouble keeping the servers running. In short, any open source project of significant size (which Debian certainly is) relies a good deal on contributions from the community.
This means running Debian (for many of us) is less like receiving a free meal and more like frequenting a restaurant where we order (and pay for) a dish we like. Then, after several years of ordering our “usual” we discover the restaurant no longer carries the dish we usually buy. At which point we need to decide if we want to order something else or visit another restaurant.
You may assume open source users are free loaders, but I contribute code, money, forum assistence and bug reports to the distributions I run. For me running a distro is an exchange (my resources for their product). My time, skillset and money goes to the project that serves my needs best. The same is true of many people. After all the people who are Debian Developers today were all Debian users in the past.
Really, do you think it is a “scary” level of entitlement that some of us only contribute to projects we continue to find useful?
No argument there.
No certainly not, but unless the distro has stated that contributing code, money, forum assistance, bug reports, etc, gives you a say in which direction the project take, then you have no demands on said direction.
If we take Debian which is the topic here, I believe you could be a DD (Debian Developer) with the contributions you listed (even translator would suffice IIRC) which would have given you a vote in this GR, and thus be able to affect the direction of the project.
This is of course on a distro by distro basis, I as a Arch user had no say in the transition to systemd two years ago, and there were certainly some voices raised against the move, with the Arch leadership stating that if someone wants to maintain the old initscripts then they will continue to be supported, no one did, and that was that.
Now if we take Debian which is the topic here, they have a technical committee which handles the technical direction of a project, they decided through vote that they would go with systemd as the default init, over Upstart which was the closest contender (in fact the other options had no votes IIRC).
Ian Jackson was not happy with the result, tried to have the chairman kicked out, and then staged a GR which didn’t pass, and then yet another which is the one we are discussing here. In this GR all DD’s were given a vote, with a vast majority of the DD’s favouring the already set path by the technical committee vote.
No, I’ve always been a fan of the ‘voting with your feet’ principle, if you chose to contribute to a project under certain conditions, and that project no longer meets those conditions then there’s nothing wrong in you no longer contributing.
However, again, unless the project states that your contributions (if any) give you a say in the direction of the project (or in this case, a say in what software developers/maintainers in that project must provide), then demanding that they do as you say is to me a ‘scary level of entitlement’.
And just to make it clear, they are not doing this to be mean to you, they have a different opinion of where the project should be heading and what they should spend their volunteered time working on.
Why not? It works for governments after all.
It’s the Debian way.
Sigh….
*facepalm
How the f–k does MPD need systemd? Seriously? This is basically going to result in Linux forking into Systemd/non systemd. There’s been a lot of talk about people moving to FreeBSD, but I predict a larger split in Linux to a newer non-systemd/non-gnome distro. The lack of choice on whether you move to systemd or not is going to piss off a ton of people. Taking existing packages that don’t depend on something and adding the dependancy is reason enough to ditch Debian. Never mind the fact that Debian still can’t get a proper multi-lib setup working with wine. There’s almost no reason to stay on the distro anymore.
Edited 2014-11-20 04:48 UTC
Fwiw, this was discovered on my Sid VM. Might be different by the time it hits Stable. Don’t know for sure.
…what? Why would it even need that. At all. Ever.
systemd require no such thing so why do something such completely wrong-headed?
Just run it in the foreground, people. It’s simple, reliable and efficient. Jesus, daemontools figured this out more than 10 years ago.
Edited 2014-11-20 04:55 UTC
I took a quick grep at MPD sources, and it looks a bit like the software has at least support for socket activation. I guess libsystemd0 might include the easiest way to support that. Typically this kind of support is completely optional, so you should be able to run the software also on systems that do not run systemd as init.
But you need to have a copy of the library present even in cases where you run the application in a way that does not use any code from there. Otherwise, you would get an error from the dynamic linker when you try to start the program.
I have to ask if you know what libsystemd0 does.
Does it
– Provide easy to use but optional functions to integrate with systemd?
– Lock the program into using only systemd forever and ever.
Uh, say what again? There is, to my knowledge, no init that *requires* software to work in any kind of non-standard way. Not even systemd.
Either you run the software in the foreground (which you should. Always.) or in the background (which you shouldn’t. No. Just don’t).
Admittedly software that can’t be run in the foreground is broken by design but it will still work.
They can try to switch to svchost.exe.
Oh wow, that would be a show worth watching. Should they ever do this, beers on me. You got the popcorn?
So … all the packages will be compiled with systemd deps in the end.
The “choice” is but an illusion.
They can link to a systemd support library. Or they can do a static link to it. Or they can just drop the source files from systemd into their program. Or they can write their very own functions to report startup success or do socket activation.
Out of those options the best one in my opinion is the shared library which makes it easy to fix bugs and uses less RAM.
But sure the software could use one of the other less good options just so the word “systemd” doesn’t show up anywhere.
Most repo packages are dynamically linked and will just come up with systemd as a dep.
Static linking is pretty rare and mostly used for portable and/or commercial software.
It’s fine for a single application, but i can’t see huge parts of the system compiling in or statically linking to their own versions of systemd. That would be horribly inefficient and a nightmare to maintain.
This isn’t a dependency on systemd, the init daemon. libsystemd0 is a library with functions for communicating with systemd.
A static link of just the one library or dropping in the source files would only add a few KB.
16K a pop apparently, but the problem is more one of manageability and efficiency.
Just think of what would happen if there is a security hole in systemd.
Just did this very ugly thing out of curiosity:
for i in `ps -ef | awk ‘{if($8 ~ /\[/){gsub(/\[/,””,$8);gsub(/\]/,””,$8);gsub(/\/.*/,””,$8)}; print $8}’`;do j=$(which $i); if [[ $j != “” ]]; then ldd $j | grep systemd; fi; done
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007f6320266000)
libsystemd-daemon.so.0 => /lib/x86_64-linux-gnu/libsystemd-daemon.so.0 (0x00007f083061c000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007f86f77a5000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007fe7e0f6f000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007fb17848c000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007f97545c0000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007fe03e829000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007fc08e3bc000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007ff40b8a6000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007fc0f8bcd000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007f461341c000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007fd1bf3e4000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007f1800d9d000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007f0a606df000)
du -csh /lib/x86_64-linux-gnu/libsystemd-login.so.0.7.1
56K /lib/x86_64-linux-gnu/libsystemd-login.so.0.7.1
du -csh /lib/x86_64-linux-gnu/libsystemd-daemon.so.0.0.10
16K /lib/x86_64-linux-gnu/libsystemd-daemon.so.0.0.10