[systemd-devel] providing backwards compatibility

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jan 17, 2014 at 09:18:49AM +0100, Kay Sievers wrote:
> On Fri, Jan 17, 2014 at 4:06 AM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> 
> > 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.
> 
> No, it will clash with the files from the old lib package. We should
> not do that, if we no longer provide the same lib.
There's nothing to clash with. Installing two versions of systemd
does not make sense, so we replace one containing the old .pc file,
with a new one, containing a different .pc file. There's no rule
that says that the .pc file must correspond one-to-one to a library.
Irrespective of whether there's a compat libsystemd-login.so in the
system, we want new binaries to link to libsystemd.so.

(Also, note that unless we marge all libraries, including -daemon,
so that there are no libraries sharing the name and so version
between systemd-old and systemd-after-the-merge, it won't be
possible to install even the libraries in parallel, because
e.g. /usr/lib/libsystemd-daemon.so.0 can't point in both directions.)

> > 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.
> 
> Same here, it creates clashes with the old files and is not strictly
> what it pretends to be with the symlink name.
OK, I buy the argument that this is a lot of magic. Downthread you
suggest, iiuc, to simply install libsystemd-login.so.0 containing a copy
of the code. This should work too and is very easy to implement.

> >> 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?
> 
> What are we trying to solve here? This is the job of the distro, it is
> what it is there for. The distro either leaves the old lib around as
> long as needed, or it re-compiles the users to use the new one.
Right now I can switch between systemd-208.rpm and systemd-209-git.rpm
without touching anything else. This is great for the user, and also
great for development. systemd is not really a project to be used
standalone by the user, it only has meaning when it is strongly
supported by other packages. We are nicely positioned in the middle of
everything, with our tentacles reaching into many distributions, so we
can prepare for the change and do it a way that avoid the flag day as
much as possible.

Zbyszek