[systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_message_get_cookie.xml man/sd_bus_new.xml man/sd_bus_open_user.xml man/sd_bus_request_name.xml src/libsystemd src/libsystemd-bus src/libsystemd-dhcp src/libsystemd-rtnl src/systemd TODO

Lennart Poettering lennart at poettering.net
Thu Jan 16 09:41:48 PST 2014


On Thu, 16.01.14 17:19, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

> 
> On 16/01/14 15:41, Lennart Poettering wrote:
> > 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.
> 
> (Please consider reviewing
> <https://bugs.freedesktop.org/show_bug.cgi?id=71818#c5> so dbus will
> stop embedding sd-daemon.[ch] :-)

Done!

> With distro hat on: we don't really care how many clones of a library
> are compiled by its "home" source package (for instance, dbus-daemon
> statically links a variant of libdbus, but that's fine, because they
> both live in the dbus source package). What we care about is that when
> there's a serious bug like a security flaw, we want to fix it as few
> times as possible, and have the rest of the distro pick it up - so we
> don't want to embed copies of libraries in our *other* source packages.

Yeah, I can understand that. But then again I think sd-daemon.c so far
was trivial enough to make this a non-issue...

But yeah, as mentioned, I am mostly leaning towards dropping the
emebeddability thing, and just telling everybody to link directly
against our lib...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list