[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:31, 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.

Nope, certainly not, we don't want to break this.

Note that all our libraries carry carefully written symbol
versioning. This means you can actually load the old e.g
libsystemd-login.so and the new libsystem.so into to the same process
and the symbols will not clash and thus not create problems. Thus a
smooth upgrade path should be possible for Debian and similar distros
which cannot just recompile everything for the new library (which is
what we'd do for Fedora).

> Do you intend to at least keep the .pc files so a recompilation would
> be sufficient?

No. We'd drop this.

Lennart

-- 
Lennart Poettering, Red Hat