[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:24, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) 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. 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.
> > 
> > I hope this makes some sense...
> Yes, it does. Thank you for the nice summary.
> 
> 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.

Well, it's true that we have been pretty good ad keeping compatibility
in the old libraries, but I am quite confident that we can do the same
for the new library. At least that's my personal goal. I'll give the new
APIs a thorough review before we make it official API and I'd welcome if
others did too, so that we have a good chance, we can keep
compatibility.

Lennart

-- 
Lennart Poettering, Red Hat