[systemd-devel] [PATCH] build-sys: merge libsystemd-login into libsystemd

[Kay Sievers]

On Fri, Jan 17, 2014 at 9:02 AM, Kay Sievers <kay at vrfy.org> wrote:
> On Fri, Jan 17, 2014 at 4:07 AM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
>
>> --- a/src/libsystemd/libsystemd.sym
>> +++ b/src/libsystemd/libsystemd.sym
>> @@ -7,8 +7,91 @@
>>    (at your option) any later version.
>>  ***/
>>
>> +/* Original symbols from systemd v31 */
>> +
>> +LIBSYSTEMD_LOGIN_31 {
>
> Do I get this right? This exports the exact same symbols from the new lib?
>
> This does not sound right. We should not try to be too smart here.
>
> Symbol versions are supposed to avoid exactly the problem this will
> create. The old symbols should not be provided by the new lib, to
> allow the loading of the old and new lib into the same process without
> clashes. We have no control which library is linked in over other
> dependencies, it's very easy to end up with both libs in one process,
> just by linking a third unrelated lib.
>
> If backwards-compat is needed, it should be provided by a compat
> package shipping the old lib, and not by double-exporting symbols from
> the old and the new lib at the same time.
>
> All this is nothing else in behavior than a SONAME bump, which is a
> very common task for distros to solve. Actually it's exactly what a
> distro is for, to solve these sorts of problems. Upstream packages
> should not try to do magic things here, it just makes things too
> fragile in the end.

What might work out instead is adding all the symbols of the libs we
want to merge to libsystemd.so, with its _correct_ symbol version
prefix LIBSYSTEMD_209, leave the original libs untouched and
standalone, not even try to do any stub wrapping.

Distros then should change the current users to the new lib and
recompile. After that, with the next release, we will remove the old
libs and have only libsystemd.so and the new names in the systemd
sources.

After that point, distros can still provide the old lib packages as
long as needed, if they care, but upstream defaults would be without
any weird magic or SONAME or file name clashes.

Kay