[systemd-devel] providing backwards compatibility

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Thu Jan 16 19:06:00 PST 2014


On Thu, Jan 16, 2014 at 09:36:47PM +0000, Colin Guthrie wrote:
> 'Twas brillig, and Michael Biebl at 16/01/14 18:22 did gyre and gimble:
> > 2014/1/16 Kay Sievers <kay at vrfy.org>:
> >> On Thu, Jan 16, 2014 at 7:00 PM, Michael Biebl <mbiebl at gmail.com> wrote:
> >>> 2014/1/16 Lennart Poettering <lennart at poettering.net>:
> >>
> >>>> Well, it can certainly continue to use and build against the old version
> >>>> for a while, no?
So there's "binary" compatibility, and "source" compatibility.
It would be nice if we could do those changes without

a) requiring recompilation ("binary")
b) requiring editing build scripts in dependent packages ("source").

For b, keeping around a .pc file which points to the *new* library
name should be enough:

- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd

On our side it's a tiny effort, and avoid a major PITA for distributions.

For a, a compatibility symlink (e.g. libsystemd-login.so.0 -> libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.

I think that if we ever decide to futher merge libraries, those
would be the steps to take.

> >>> 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? The lib is packaged separately, isn't it? What does it have to do
> >> with the systemd package?
> > 
> > Packaged separately in the sense that the systemd source package
> > builds a libsystemd-daemon0 binary package (among others).
> > In systemd v209 we could no longer build such a libsystemd-daemon0
> > binary package from the systemd source package.
> > We'd have to introduce a separate source package (based on systemd pre
> > 209) named differently then systemd if we want to be able to continue
> > to build libsystemd-daemon0.
> 
> Could we not provide a libsystemd-daemon.so.0 that is just a stub and
> links to libsystemd.so.X and just calls the functions therein? That way
> the API could still be provided with the old lib (and old .pc files too)
> until such times as everything is updated. I would presume the name
> mangling would allow for this to work OK with some clever tricks here
> and there... (correctly me if I'm wrong)
Yes, I think that's the way to go.

> This would surely be the nicest way to handle things during any
> transition phase and could be turned off with a configure switch?

Zbyszek


More information about the systemd-devel mailing list