On Thu, 16.01.14 18:27, Michael Biebl (mbi...@gmail.com) wrote: > > 2014/1/16 Lennart Poettering <lenn...@poettering.net>: > > On Thu, 16.01.14 17:33, Michael Biebl (mbi...@gmail.com) wrote: > > > >> > >> 2014/1/16 Zbigniew Jędrzejewski-Szmek <zbys...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel