3 ms·

From what I can tell, all this means is that Debian packagers will have to drop hard dependencies on components of systemd in many cases. I see nothing objectio

From what I can tell, all this means is that Debian packagers will have to drop hard dependencies on components of systemd in many cases. I see nothing objectionable with this, as there have been some absolutely inane things going on at the packaging sphere. For example, treating the fact that upstream provides a systemd unit file as a dependency on systemd. To some extent, this can also be blamed on inherent weakness in most contemporary package managers that lack the ability to easily express multiple classes of dependencies, and treat everything as a hard one. That said, we still keep saying the same shoddy sentiments from systemd proponents. "Can't we just move on?" "systemd hasn't had any problems for me. Don't like it? Leave it!", "This must be Canonical.", so on and so forth. The /r/linux thread is a depressing clusterfuck of uninformed proponents, as always.

_delirium 12y ago
One thing that is not making the discussion clearer is that many people are failing to distinguish between two different kinds of dependencies. Depending on a systemd library versus depending on the systemd daemons running are quite different scenarios. It would be ideal for the latter to be minimized, but the former is not a problem at all. To take an analogy, plenty of Debian packages depend on libselinux1, because they feature optional selinux functionality, and not depending on libselinux1 would result in broken symbol tables. But most of these packages work perfectly fine without SELinux configured (as you might guess, since very few people actually have SELinux configured). Having libselinux1 on your system does not require you to use SELinux, and imo it would be unreasonable to complain that your system is now "infected" by SELinux because you can't uninstall libselinux1. It's just a library, like many others, and having it on your system doesn't impose policy requirements on you as administrator or user. Yet people are making exactly that argument with systemd, complaining that some systemd library or another is on their system and thereby "infecting" it. Rather than focusing on the more legitimate issue of which packages actually require systemd daemons to be configured/running.
- digi_owl 12y ago
  Do systemd even have such a "inert" lib? Best i can tell everything happens via dbus (to be replaced with kdbus), and that again requires that systemd is running as pid 1 (as it will refuse to run as anything else, unless it is inside a namespace governed by another systemd as pid 1).
  - _delirium 12y ago
    Sure, that's what libsystemd0 is. It's just a shared library, like libselinux1, that lets applications be compiled with systemd support. It doesn't depend on systemd itself, or start up any daemons. It's quite possible to have a package that's compiled with support for two different logging systems, for example. In that case it would depend on the libraries for both of them, but would only actually use the one that is configured. On the other hand, it's possible an application actually does require systemd running to function, in which case it would depend on 'systemd' as well, not only 'libsystemd0'.
EmanueleAina 12y ago
I agree with the sentiment of not having hard deps on systemd. In fact many teams already put some actual work toward that goal (eg. the GNOME team) but the main problem I see is who is mandated to do this work. As an example, GNOME upstream requires logind if you don't want to rely on the bug-ridden and unmaintained ConsoleKit. AFAIK the Debian GNOME team does not wish to enable the ConsoleKit backend on Linux due to not having enough resources to test it and nobody stepped up to maintain it. While they initially represented this fact with a dependency on systemd, but ultimately said dependency is now on libpam-systemd, which depends on systemd or systemd-shim. So it's not like Debian teams are against what the GR proposes, but it's easy to see the GR as a way to force them to do work that they don't have the resources to do.

_delirium 12y ago

One thing that is not making the discussion clearer is that many people are failing to distinguish between two different kinds of dependencies. Depending on a systemd library versus depending on the systemd daemons running are quite different scenarios. It would be ideal for the latter to be minimized, but the former is not a problem at all. To take an analogy, plenty of Debian packages depend on libselinux1, because they feature optional selinux functionality, and not depending on libselinux1 would result in broken symbol tables. But most of these packages work perfectly fine without SELinux configured (as you might guess, since very few people actually have SELinux configured). Having libselinux1 on your system does not require you to use SELinux, and imo it would be unreasonable to complain that your system is now "infected" by SELinux because you can't uninstall libselinux1. It's just a library, like many others, and having it on your system doesn't impose policy requirements on you as administrator or user. Yet people are making exactly that argument with systemd, complaining that some systemd library or another is on their system and thereby "infecting" it. Rather than focusing on the more legitimate issue of which packages actually require systemd daemons to be configured/running.

digi_owl 12y ago
Do systemd even have such a "inert" lib? Best i can tell everything happens via dbus (to be replaced with kdbus), and that again requires that systemd is running as pid 1 (as it will refuse to run as anything else, unless it is inside a namespace governed by another systemd as pid 1).
- _delirium 12y ago
  Sure, that's what libsystemd0 is. It's just a shared library, like libselinux1, that lets applications be compiled with systemd support. It doesn't depend on systemd itself, or start up any daemons. It's quite possible to have a package that's compiled with support for two different logging systems, for example. In that case it would depend on the libraries for both of them, but would only actually use the one that is configured. On the other hand, it's possible an application actually does require systemd running to function, in which case it would depend on 'systemd' as well, not only 'libsystemd0'.

EmanueleAina 12y ago

I agree with the sentiment of not having hard deps on systemd. In fact many teams already put some actual work toward that goal (eg. the GNOME team) but the main problem I see is who is mandated to do this work. As an example, GNOME upstream requires logind if you don't want to rely on the bug-ridden and unmaintained ConsoleKit. AFAIK the Debian GNOME team does not wish to enable the ConsoleKit backend on Linux due to not having enough resources to test it and nobody stepped up to maintain it. While they initially represented this fact with a dependency on systemd, but ultimately said dependency is now on libpam-systemd, which depends on systemd or systemd-shim. So it's not like Debian teams are against what the GR proposes, but it's easy to see the GR as a way to force them to do work that they don't have the resources to do.