On Thu, 16.01.14 17:24, Zbigniew Jędrzejewski-Szmek (zbys...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel