How is wget depending on systemd?

So I had to look this up.

On Arch at least, wget depends on util-linux (package containing kernel tools like mount, dmesg etc.): https://www.archlinux.org/packages/extra/x86_64/wget/ And util-linux depends on systemd: https://www.archlinux.org/packages/core/x86_64/libutil-linux...

I have to assume this is Arch-specific, because I can't anything that basic as util-linux including a dependency on a specific init tool (and given there are still distros using other inits than systemd and still working fine...)

The systemd is a make dependency only. Unless you plan on compiling it yourself, you don't need systemd to run it.

    ~ $ y -Qi libutil-linux | grep Depends
    Depends On     : None

EDIT: conversely, these are the packages depending on systemd:

    ~ $ y -Qi systemd | grep Required | fmt
    Required By    : accountsservice  chromium  colord  crda  cups
    device-mapper  gnome-session  lib32-systemd  libgdm  libgusb  libpulse
    libusb  libvirt  libwacom  lvm2  media-player-info  mesa  mkinitcpio
    netctl  polkit  procps-ng  qt5-base  qtwebkit  rtkit  spotify  subversion
    systemd-sysvcompat  udisks2  upower  xf86-input-evdev  xf86-video-ati
    xf86-video-modesetting

As a sysadmin and developer I don't understand this systemd-hate. If you ever have written a /etc/init.d script for a python non-daemoning script running in a virtualenv, or something to the same effect, you'd notice the improvement over SysV init scripts.

Upstart is nice too, but as a Linux desktop user I love socket activation: I can have cups, avahi and other optional/non-critical daemons "active" but not actually using any resource, until effectively used by some other process.

>If you ever have written a /etc/init.d script for a python non-daemoning script running in a virtualenv, or something to the same effect, you'd notice the improvement over SysV init scripts.

These are solved problems. You're creating a bunch of low level OS spaghetti because you don't want to have to write a shell script for your software? That is not a responsible decision-making process, that's moving the mountain to you.

And making it harder for someone to come afterwards and untangle the mess.

I swear a earlier discussion here on this very site had someone honestly suggest the usage of strace to figure out why systemd failed to boot.

Countless subtle race conditions and security issues in the shell spaghetti that makes up real-world init scripts indicate that it's not a "solved problem".

That's probably because util-linux has a command, logger, which can optionally log to systemd's journal. Take a look at http://man7.org/linux/man-pages/man1/logger.1.html.

Probably accidentally, due to a poorly abstracted dependency chain.

Debian:

[wget]-depends-[libuuid1]-recommends-[uuid-runtime]-depends-[libsystemd0]

Ph’nglui mglw’nafh Cthulhu R’lyeh wgah’nagl fhtagn