On Fri, Jan 17, 2014 at 10:28 AM, Colin Guthrie <gm...@colin.guthr.ie> wrote:
> 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
>> <zbys...@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.The header will not change, the new lib will install them too. So your old -devel package cannot be installed in parallel. >>> 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. No, it's not ok to rely on such magic. The SONAME is not the same, and such hacks do not belong there. >>>> 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. It's just one "echo" and you have that file if you need it. > 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. We should just keep the libs as they are for a release, but provide the functionality in the new lib under its correct name, and post stuff over. After that's done we should see what's actually left to cover, I doubt there is much. There is no need to solve that problem at this very moment, we can just ship the old stuff for a short while. This year will bring huge flag day compat breaks. We will drop all old D-Bus support, we will require on a bleeding edge kernel, and so on. I think mangling around a pc file name is absolutely nothing compared what the next months will bring us. It's just not worth when you look at the big picture what will happen soon. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
