[systemd-devel] merging libsd-id128 and libsd-login with libsystemd

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 16, 2014 at 04:41:48PM +0100, Lennart Poettering wrote:
> So I am pretty sure libsystemd-id128, libsystemd-login,
> libsystemd-journal should just end up in a single libsystemd.so together
> with the event loop, the bus, the asyncns stuff and more. All this
> functinality requires each other, and should nto pull in its own copy of
> src/shared/*.c each time.
I now pushed a series of patches which merge libsystemd-id128 and
libsystemd-login into libsystemd. I also changed the linker to gold by
default, becuase bfd had a bug [1]. It has since been fixed, but not
released yet, and anyway gold is minimally faster. When running distcheck,
which uses -flto, a bug [2] in gold was uncovered. I worked
around it by disabling lto for the compat libsystemd-login. I doesn't
matter much anyway for this lib. All in all, this doesn't give a good feeling...
I wouldn't be surprised if other issues pop up. I guess it's better to
do this now and potentially revert than right before release.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=16467
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=16504

libsystemd-journal is more complicated. It uses libsystemd-label, which
in turn uses libselinux. Doing a straighforward merge would mean that
everything is linked with libselinux. I think that the idea of splitting
the reporting side of sd-journal and moving it to libsystemd, while
keeping the rest separate, might be a good idea. Comments?

Zbyszek

> There are some exceptions to this though. For example, I am unsure about
> libsystemd-daemon: it's relatively easy to maintain this in its own lib,
> sicne so far it actually doesn't use any of the shared code, because
> its' embeddable. But then agaiun, given that this library evolves too,
> and given that distros generally don't like embedding anyway, we should
> probably just merge it into libsystemd.so too, in particular since the
> functions it provides are really low-level stuff. libsystemd-dhcp
> however really sounds like something that will always be consumer of services, never
> provider of services from this new libsystemd.so, and the set of
> programs making use of it will always be very small, so we can and
> should certainly keep it a seperate lib.