[systemd-devel] providing backwards compatibility

[Colin Guthrie]

Hi,

As far as I understand things, the goal is to be API compatible in terms
of function calls, but change the name of the pc files which is an API
break. Is this a correct summary? (if not then some of my comments below
don't work :D)

'Twas brillig, and Kay Sievers at 17/01/14 08:18 did gyre and gimble:
> 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.

I guess Fedora do things differently, but we ship pc files in the -devel
package, so there would be no clashes with the old lib package for us...
This would be very useful.

>> 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.

If said symlink is binary compatible, you could just ship an updated
version of that package. Sure it's a bit of a lie in that it's not a
real lib but I'd be OK with that personally (esp as it has to be done by
hand). If not then a stub lib rather than symlink wouldn't be lying so
is still OK as a plan if compatibility is desirable.

>>> 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.
> 
> Please do not mix code (upstream) and system composition
> (distribution) too much here. It's all really the same model as an
> SONAME bump, something that happens every day.

Well you're also forcing "code" work onto "system composition" people as
they actively need patch things when we could provide an easy mechanism
for them to avoid this. This is different to an SONAME bump which
generally doesn't change the name of the .pc file and will often be fine
with a rebuild without any code modification.

As a disro maintainer, I'd be happy enough to ship a new systemd then
rebuild needed packages accordingly. What I'd be less happy about is the
API change that means my configure scripts don't work any longer and I
have to push patches into the consumer packages. There is no real need
for compat libs here, just compat .pc files. So from a distro
perspective I'd be happy with just that.


Perhaps you'd argue that such compat .pc files should just be shipped in
the distro's systemd package and not upstream? What I'm a little
confused about is that RHEL is going to be shipping systemd 207 or 208
and these "old" .pc names will be kinda embedded for quite some time.
Therefore consumer upstreams will be under pressure to keep the old
names in their configure scripts for a good number of years. If we
change them then we're forcing them to do an if/else structure in their
configures to check for both which is a little nasty. Surely shipping
compat .pc files just makes life easier for all concerned until there is
the need for a "real" API break?


Forgive me if I've misunderstood some other details of the change.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/