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

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]



On Sat, 27 Aug 2016 at 10:33:36 +0300, Dmitry Bogatov wrote:
> 
> > > >  * conntrackd & systemd are very good integrated (using libsystemd)
> > >
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no.  While I do think packages should keep sysvinit
> > support as long as it continues to work and doesn't make other paths
> > worse, I don't think it makes sense to omit linking to libsystemd, or to
> > dlopen it at runtime.
> 
> Extra useless dependency. This is case when I miss Gentoo's use-flags.

Once per thread about systemd, I point out that dbus-daemon links to both
libapparmor and libselinux - which results in at least one useless library
for literally everyone with dbus installed, since "major" LSMs don't
stack, so nobody can possibly be using both AppArmor and SELinux at the same
time. Oddly enough, nobody has complained about that, only about
libsystemd...

This is the price you pay for using a binary distribution like Debian
(or Fedora, or SuSE, or Devuan, or whatever). I don't use SELinux,
but libselinux is pseudo-Essential, so I have to have it - and that's fine,
the engineering effort required to make it optional would "cost" more
than the disk space it takes up.

In particular, changing programs to dlopen libsystemd is actively harmful -
it is not just a waste of effort, it would also defeat Debian's
deb-symbols(5) mechanism.

> But I agree, that changing programs to dlopen libystemd is too much
> problem. Too much of them. But I think we can do better.
> 
> Like compat package, which provides libsystemd.a static library and
> headers, that mirrors interface of libsystemd. This library would
> forward call to actual libsystemd, if it exists and return error, if
> it does not.

You mean like libsystemd, which looks in /run to see whether systemd is in
use, talks to it if it is, and returns some suitable error code (-ENOSYS?)
if it isn't? :-)

Now that we have versioned Provides, you could substitute a stub version
of the shared libsystemd without recompiling *anything*, if it matters
so much to you. Make sure to tell the libsystemd maintainers you have
done so, so that they can make reportbug report whether the stub version
is installed, and reassign all bug reports involving the stub version to
be analyzed by its maintainer and minimize the amount of their time that
is unnecessarily taken up by it.

I honestly don't think this is a good idea even if you will never run
systemd, though. One of the reasons that is frequently given for
avoiding systemd is reducing the (perceived or real) complexity of the
overall system... but every time there's a swappable component, that's
an increase in complexity. The overall system consisting of libsystemd
and your stub/shim libsystemd is more complex for Debian to support,
with more things that can go wrong, than libsystemd itself.

    S


Reply to: