4 ms·

Core package bsdutils predepends on libsystemd0. Now it is impossible for any Debian jessie systems to be without systemd code. https://packages.debian.org/sid

by xfs 12y ago

Core package bsdutils predepends on libsystemd0. Now it is impossible for any Debian jessie systems to be without systemd code. https://packages.debian.org/sid/bsdutils https://packages.debian.org/sid/bsdutils

geofft 12y ago
That's moving the goalposts in a significant way. Debian has always been of the philosophy that binaries that have runtime-optional support for something link libsomething and have a dependency on it, but there cannot generally be a dependency from libsomething to the actual something package. For instance, openssh-client depends on libgssapi-krb5-2 and libselinux1, but neither of those packages have a dependency on the Kerberos 5 userspace clients or on SELinux being configured or enabled, respectively. If you happen to install Kerberos or enable SELinux, then openssh-client will work fine without a recompile (because Debian doesn't have USE flags). If you don't, the libraries will just do nothing. I think SELinux is a terrible and misguided idea that subverts the UNIX philosophy, adds needless complexity, and also doesn't work, but I have no objection to libselinux1 being installed. Same thing with bsdutils and libsystemd0. The discussion has never been about being "without systemd code" as if it were a noxious poison. (It's free software, I would _hope_ people incorporate good code from it into other packages.) It's about being without systemd, the init system, and if bsdutils did depend on a particular init system, it would be flagrantly in violation of the Technical Committee resolution.
- srslack 12y ago
  >subverts the UNIX philosophy When was Linux or GNU following the Unix philosophy? Can you name a figurehead who says it ever did?
  - geofft 12y ago
    It never completely did, and I certainly don't think it should. I was just referencing the similar arguments against systemd.
- xfs 12y ago
  This libsystemd points to a dangerous habit of the certain group of developers who prefer strong interdependency and monolithic architecture. In similar way, you have libdbus which is technically not the actual dbus, but tries anything to launch dbus processes if loaded and initialized as a library. And gconf libraries which ship daemon executables and also launch daemons from library. Libsystemd is apparently not doing such right now, but given its windows.dll like nature, it's a reasonable concern to have.
  - geofft 12y ago
    > In similar way, you have libdbus which is technically not the actual dbus, but tries anything to launch dbus processes if loaded and initialized as a library. That can only happen if the dbus executables are installed; libdbus-1-3 Recommends but does not Depend on dbus. This is the standard way of things for everything in Debian, and the dbus packaging is no different from the Kerberos packaging here. As I mentioned, it would be in violation of the tech-ctte ruling if depending on libsystemd0 also brought in systemd itself as a hard dependency. > it's a reasonable concern to have. The entire worldview of systemd is that you shouldn't be spawning things from your current environment (cf. daemonizing in /etc/init.d/foo), you should ask some parent keeper process to spawn the executable. It sounds like it would involve systemd doing the exact opposite of what it currently does if libsystemd were to fork-and-exec much of anything. For instance, systemd is obsoleting the setuid dbus-daemon-launch-helper, which I am super excited about, having gotten on dbus-daemon-launch-helper's bad side far too many times.
scarygliders 12y ago
Yep. You noticed that too. I found this out by trying to remove all traces of systemd from my Jessie/Sid installation, found out that I couldn't get rid of libsystemd0 because bsdutils depends on it. That's the same bsdutils that you can't really do without. It's almost as if systemd was being forced upon you no matter what.

by xfs 12y ago

geofft 12y ago

That's moving the goalposts in a significant way. Debian has always been of the philosophy that binaries that have runtime-optional support for something link libsomething and have a dependency on it, but there cannot generally be a dependency from libsomething to the actual something package. For instance, openssh-client depends on libgssapi-krb5-2 and libselinux1, but neither of those packages have a dependency on the Kerberos 5 userspace clients or on SELinux being configured or enabled, respectively. If you happen to install Kerberos or enable SELinux, then openssh-client will work fine without a recompile (because Debian doesn't have USE flags). If you don't, the libraries will just do nothing. I think SELinux is a terrible and misguided idea that subverts the UNIX philosophy, adds needless complexity, and also doesn't work, but I have no objection to libselinux1 being installed. Same thing with bsdutils and libsystemd0. The discussion has never been about being "without systemd code" as if it were a noxious poison. (It's free software, I would _hope_ people incorporate good code from it into other packages.) It's about being without systemd, the init system, and if bsdutils did depend on a particular init system, it would be flagrantly in violation of the Technical Committee resolution.

srslack 12y ago
>subverts the UNIX philosophy When was Linux or GNU following the Unix philosophy? Can you name a figurehead who says it ever did?
- geofft 12y ago
  It never completely did, and I certainly don't think it should. I was just referencing the similar arguments against systemd.
xfs 12y ago
This libsystemd points to a dangerous habit of the certain group of developers who prefer strong interdependency and monolithic architecture. In similar way, you have libdbus which is technically not the actual dbus, but tries anything to launch dbus processes if loaded and initialized as a library. And gconf libraries which ship daemon executables and also launch daemons from library. Libsystemd is apparently not doing such right now, but given its windows.dll like nature, it's a reasonable concern to have.
- geofft 12y ago
  > In similar way, you have libdbus which is technically not the actual dbus, but tries anything to launch dbus processes if loaded and initialized as a library. That can only happen if the dbus executables are installed; libdbus-1-3 Recommends but does not Depend on dbus. This is the standard way of things for everything in Debian, and the dbus packaging is no different from the Kerberos packaging here. As I mentioned, it would be in violation of the tech-ctte ruling if depending on libsystemd0 also brought in systemd itself as a hard dependency. > it's a reasonable concern to have. The entire worldview of systemd is that you shouldn't be spawning things from your current environment (cf. daemonizing in /etc/init.d/foo), you should ask some parent keeper process to spawn the executable. It sounds like it would involve systemd doing the exact opposite of what it currently does if libsystemd were to fork-and-exec much of anything. For instance, systemd is obsoleting the setuid dbus-daemon-launch-helper, which I am super excited about, having gotten on dbus-daemon-launch-helper's bad side far too many times.

scarygliders 12y ago

Yep. You noticed that too. I found this out by trying to remove all traces of systemd from my Jessie/Sid installation, found out that I couldn't get rid of libsystemd0 because bsdutils depends on it. That's the same bsdutils that you can't really do without. It's almost as if systemd was being forced upon you no matter what.