Re: libsystemd [was: Re: Is missing SysV-init support a bug?]
On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > 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.
But _why_ would you want to avoid libsystemd? Its only bad effect is
wasting a negligible amount of disk space and a few pages memory. Do you
recompile for example clementine/amarok/rhythmbox/banshee without libgpod
just because you don't own such an ancient piece of iCrap? Unless you go
really deeply embedded, fighting such slight bloat is not worth your time.
_This_ is bloat:
[41270.363188] Out of memory: Kill process 14533 (firefox) score 104 or sacrifice child
[41270.363362] Killed process 14533 (firefox) total-vm:3598348kB,
anon-rss:1695684kB, file-rss:46384kB, shmem-rss:26904kB
This is not:
Even if libsystemd0 was completely loaded into memory, count how many orders
of magnitude less waste it would be than a browser.
> If I don't like libsystemd dependency, I am in much worse position,
> since I have to rebuild really a lot of packages. Yes, we have
> `angband.pl' repository, but this not systematic solution.
As I'm the guy behind that repository, my reason for recompiling everything
without libsystemd is not pruning this small dependency -- it's a cheap way
to ascertain programs use non-systemd code paths. It'd be nice if all of
them did the detection at runtime, but unfortunately some (like policykit-1)
have mutually exclusive code paths that get chosen at compile time. By
compiling with no systemd libraries, I can be sure all such pitfalls are
avoided. But that's only a short-term gain.
An imaginary friend squared is a real enemy.