[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

Michael Biebl mbiebl at gmail.com
Thu Jan 16 10:00:56 PST 2014


2014/1/16 Lennart Poettering <lennart at poettering.net>:
> 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?

We'd have to make pre-systemd-209 and systemd-209 packages
co-installable (different source package names etc.) to be able to
continue to provide the old version. That is not really fun.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


More information about the systemd-devel mailing list