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

> So not having to go through soname transitions affecting potentially
> quite a few packages would definitely be a big plus.

Well, Debian is much better at doing smooth soname transitions, since it
encodes the soname in the package name. With the symbol versioning we do
this should really avoid any troubles...

Lennart

-- 
Lennart Poettering, Red Hat