On Tue 08 Jul 2014 at 13:00:24 +0200, berenger.mo...@neutralite.org wrote: > Why should desktops and end-user applications have to depend on > systemd's parts? For mpd, for example. Ok, it's started as daemon by > default, but users can run instances of it for themselves if they > want, and mpd is portable. Why should it have a hard dep on > libsystemd-daemon0 (it had no dep like this previously, and I doubt > mpd will stop their support for windows or bsd... so it must be > enabled by some sort of flag?). > Indeed, it's not systemd's fault if those applications depends on > it. But it's a part of the noise around systemd.
Let's look at what the mpd folks have to say. https://github.com/lintweaker/mpd-dsd-018/blob/master/INSTALL libsystemd-daemon - http://freedesktop.org/wiki/Software/systemd/ For systemd activation. It's an optional dependency but mpd upstream see some use for it. Maybe it's socket activation; maybe not; I do not know. Other optional dependencies are libcdio and libcurl. My shallow experience of Debian packages is that maintainers build them to have as much functionality as possible. They do not alter upstream's intentions on a whim. But Debian's mpd maintainers know I don't want to play audio CDs with mpd and that I hate curl [1]. Nevertheless they ignore my complaints and still build their packages with both. Why not look at libsystemd-daemon0 as just another library which performs a useful funtion on a system? Or file a bug to rename it to libnotsystemd-daemon0. :) [1] I am allowed to hate curl because I do not use it and do not understand what it does. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/08072014184146.839998c31...@desktop.copernicus.demon.co.uk
