[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]

On Thu, 16.01.14 18:27, Michael Biebl (mbiebl at gmail.com) wrote:

> 
> 2014/1/16 Lennart Poettering <lennart at poettering.net>:
> > On Thu, 16.01.14 17:33, Michael Biebl (mbiebl at gmail.com) wrote:
> >
> >>
> >> 2014/1/16 Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl>:
> >> > I am also a bit worried about so-bumps: currently we have very nice backwards
> >> > compatibility, without any API removals. -daemon, -id128, -journal, -login
> >> > are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to
> >> > keep this way, among other reasons, because it's much bigger, and much more
> >> > experimental.
> >>
> >> I'd prefer if the libraries were kept separate, at least for the ones
> >> for which it is possible without it beeing to painful.
> >> At least libsytemd-daemon should imho be kept separate with a stable API/ABI.
> >> We already have 10+ reverse dependencies of that library in Debian and
> >> the list is constantly growing.
> >
> > Sure, but as mentioned, if we end up merging libsystemd-daemon.so into
> > libsystemd.so, both would be parallel installable and would not result
> > in symbol clashes. Thus, the transition should be smooth... (Also note
> > that it would still be the same scope, so if you are concerned about
> > pulling in incompatible code into non-systemd boots, there's shouldn't
> > be a problem)
> 
> Well, since you plan to drop the .pc files I wouldn't really call the
> transition smooth, as every package would need sourceful changes to
> their configure check to now use a different .pc file name.

Well, it can certainly continue to use and build against the old version
for a while, no?

> Having to touch every affected package is something I'd like to avoid
> especially since I don't quite see the benefit of folding libsd-daemon
> into libsd.

Well, we currently do a lot of stuff manually in sd-daemon.c which
if merged (and with the embeddability requirement dropped) we could just
use functions from util.c for. (Remember that sd_notify() discussion on
debian's ctte ML, where some people got irritated by the perceived
complexity of the function...?) Also, the library evolves. For example,
I recently added calls to simplify the WATCHDOG_USEC stuff to the lib,
and sooner or later it just gets annoying to hack these new things
without src/shared/*.c available...

I mean, that's probably the key issue here: 

Hacking with src/shared/*.c and with _cleanup_ and other gcc macros
defined is fun. Hacking without it is so much nastier these days... I
really am put off by that nowawadays. It's probably the one big reason
why I am doing such a shitty job at Avahi maintaining these days:
hacking without the luxury of the systemd internal APIs and syntactic
sugar is just not fun anymore...

Lennart

-- 
Lennart Poettering, Red Hat