[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Removing libsystemd0 from a non-systemd system

David Griffith writes:
> On Sun, 6 May 2018, The Wanderer wrote:
>> On 2018-05-06 at 21:25, David Griffith wrote:
>>> What's the point of allowing libsystemd0 to exist when systemd has
>>> been purged?
>> So that programs which interface with systemd can detect whether or not
>> systemd is present, and fall back to alternate code paths when it's not.
>> As I understand matters (without having actually dug into the code),
>> that detection code literally is what libsystemd0 *is*; when systemd is
>> present, it passes through function calls to be handled in appropriate
>> places, and when systemd is not present, it returns an appropriate
>> default or failure value.
> I was under the impression that systemd-shim provided this
> functionality.

No, that's wrong.

> When I look at
> https://packages.debian.org/stretch/systemd-shim and
> https://packages.debian.org/stretch/libsystemd0, their functions
> appear to be identical except that the latter actually does talk to
> systemd if systemd is present.

systemd-shim provides a daemon that allows some parts of systemd to work
even when systemd does not provide pid-1.  For desktop systems that
means systemd-logind will be able to run.  (logind wants to start/stop
some processes using an interface provided by systemd's pid-1 to manage
cgroups; there is a fork (elogind) that just merged the cgroup
management into the logind binary.)

libsystemd0 is a shared library providing some functions to applications
linking against the library.  Some parts work without any daemons
installed, some parts want to talk to some daemons provided by systemd
services, depending on which functionality one uses.

A daemon with a Dbus interface and a shared library are quite different
things, especially when taking about why some package dependencies


Reply to: