[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

Kay Sievers kay at vrfy.org
Thu Jan 16 08:37:46 PST 2014


On Thu, Jan 16, 2014 at 5:31 PM, Michael Biebl <mbiebl at gmail.com> wrote:
> 2014/1/16 Lennart Poettering <lennart at poettering.net>:
>> So I am pretty sure libsystemd-id128, libsystemd-login,
>> libsystemd-journal should just end up in a single libsystemd.so together
>> with the event loop, the bus, the asyncns stuff and more. All this
>> functinality requires each other, and should nto pull in its own copy of
>> src/shared/*.c each time.
>>
>> 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...
>
> Would that mean you intend to break existing software which uses those
> libraries, especially libsystemd-daemon.
> Do you intend to at least keep the .pc files so a recompilation would
> be sufficient?

The old lib should be able to stay around for older compiled tools as
long as needed.
Linking against the new lib should not create conflicts when the new
lib provides the same symbols.

Kay


More information about the systemd-devel mailing list