Don't Use Fedora's Fedup Right Now Due To A Bug With Systemd

Exactly. Gnome and, as explained above, KDE *choose* to use systemd - or better said, certain interfaces that systemd provides - because they find these interfaces useful. They provide useful features, or make development simpler, or provide robustness, or there's some other improvement somewhere.

That's a big problem with anit-systemd proponents - often they say "I don't need this stuff". Well, you may not, but application developers do. And that's why applications are getting a dependency on systemd. Changing that will not happen through forum complaints, but through doing work, writing code. Like Debian is doing with systemd-shim. Because of systemd-shim, Gnome on Debian is fully functional without systemd being PID1.

1) Some users don't want/can't (policy at workplace/school... etc) use systemd.
2) Projects who make their stuff _rely_ on systemd feature, know what they signed up for and that they will lose some users (and systemd-haters have every right to complain about their decision).
3) Developers can do whatever they want in open source world (unless they work for _some_company_ which ultimately controlls some OSS projects).
x) "anit-systemd proponents" -- really??? I mean.. I don't usually pick on grammar, but... srsly?

[Gusar]

The systemd developers are planning on making udev dependent on systemd in the future

No, they're not. What will happen is udev will switch to kdbus. Totally different thing. Sure on a systemd system it'll be systemd's job to set up kdbus policies. But there's nothing preventing someone to write a non-systemd method to set up kdbus, thus allowing the kdbus-enabled udev to run without systemd.

About KDE, Kwin will require logind on wayland. *logind*, not systemd. More info here. So, similar to above, using Kwin/wayland without systemd will require that someone writes an alternative logind implementation. Or use logind with Debian's systemd-shim.

Isn't that Gnome's choice, rather than systemd's?

Exactly. Gnome and, as explained above, KDE *choose* to use systemd - or better said, certain interfaces that systemd provides - because they find these interfaces useful. They provide useful features, or make development simpler, or provide robustness, or there's some other improvement somewhere.

That's a big problem with anit-systemd proponents - often they say "I don't need this stuff". Well, you may not, but application developers do. And that's why applications are getting a dependency on systemd. Changing that will not happen through forum complaints, but through doing work, writing code. Like Debian is doing with systemd-shim. Because of systemd-shim, Gnome on Debian is fully functional without systemd being PID1.

[makomk]

Oh, and it turns out the version of systemd in the Fedora 21 beta is actually somewhere between 216 and 217, so it has a slightly different implementation of the "shut down 15 minutes into booting" feature that's configured system-wide rather than in job files but is still enabled by default and still cannot be overridden by unit files that expect to take longer than 15 minutes.

[makomk]

I keep hearing this. What dependencies are these? Is there any software other than Gnome that requires systemd? Isn't that Gnome's choice, rather than systemd's? These are honest questions. I use systemd as it is the default in my distro of choice, and haven't had any reason to switch to any alternatives.

I think Gnome's the main one right now, though some KDE functionality (like suspending from the GUI) depends on it indirectly. The systemd developers are planning on making udev dependent on systemd in the future, though, at which point you'll need it to have a functioning desktop/laptop/server Linux install - udev's basically essential to be able to even boot properly on those platforms.

According to the systemd changelog, this option is configurable. You can enable/disable it or change the timeout duration PER UNIT FILE! .. So can we really say that this is a systemd bug and not carelessness by fedora/Fedup devs?

The problem is that the timeout duration isn't set on the unit file that's causing the boot delay, it's set on the job representing the entire boot process and there's absolutely no way for other unit files that are expected to take long enough that they'll hit the limit to override it. Oh, and the systemd developers were the ones that decided to configure it this way.

[jbernardo]

According to the systemd changelog, this option is configurable. You can enable/disable it or change the timeout duration PER UNIT FILE! .. So can we really say that this is a systemd bug and not carelessness by fedora/Fedup devs?

Not if you're one of the cultists - for them, systemd doesn't have bugs, and every unbeliever is a hater.

[computerquip]

It is not carelessness since fedup developer wasn't aware that this new feature was introduced in systemd. It is just something that was caught during testing in an alpha release. Considering that is the whole purpose of pre-releases, I don't see why anyone should be concerned too much about it.

Because the word systemd is there and people are haters.

[RahulSundaram]

According to the systemd changelog, this option is configurable. You can enable/disable it or change the timeout duration PER UNIT FILE! .. So can we really say that this is a systemd bug and not carelessness by fedora/Fedup devs?

It is not carelessness since fedup developer wasn't aware that this new feature was introduced in systemd. It is just something that was caught during testing in an alpha release. Considering that is the whole purpose of pre-releases, I don't see why anyone should be concerned too much about it.

[renkin]

According to the systemd changelog, this option is configurable. You can enable/disable it or change the timeout duration PER UNIT FILE! .. So can we really say that this is a systemd bug and not carelessness by fedora/Fedup devs?

[dungeon]

N

That is a problem with Debian's package management, not systemd's dependencies, and since you are using Testing I am sure that you filed a bug report already and soon will get an answer.

It is not problem with package managment, as i quote Lennart earlier that is problem with changed systemd dependencies and libs, even Lennart say i am "Sorry for the complexities this involves!"

We merged libsystemd-journal.so, libsystemd-id128.so, libsystemd-login
and libsystemd-daemon into a a single libsystemd.so to reduce code
duplication and avoid cyclic dependencies (see below).

http://lists.freedesktop.org/archive...ry/017146.html

But of course that will be fixed in Debian testing as part of that transition hopefully

[gens]

N

That is a problem with Debian's package management, not systemd's dependencies, and since you are using Testing I am sure that you filed a bug report already and soon will get an answer.

there is a bug report
problem is in glib, in that it does a lot of unrelated things
so even though there is no technical reason, there is a bad refactoring reason