polkit-1 for elogind

[Ian Jackson]

Ian Jackson writes ("Re: polkit-1 for elogind"):
> I am looking at this now.  I will write up what I think I have
> discovered.

(Sorry that this writeup sounds a little distant; I wrote it with a
more general audience in mind than Mark and this list...)


I investigated the situation with polkit and libelogind.  (The
background is that we have had mixed reports about the results of
running stock Debian policykit-1 with elogind.)  I read parts of the
source code of policykit-1 in Mark Hindley's branch; did some minor
cross-checks against sid's policykit-1 and elogind etc.


In the policykit source code the key thing seems to be the class
PolkitBackendSessionMonitor.  AFAICT there is (in current upstream)
only one implementation, polkitbackendsessionmonitor-systemd.c.
This links using conventional dynamic linking to libsystemd.

In existing OS's with elogind (at least in Devuan and I imagine the
same is true eg of Guix) autoconf arrangements are made so that
libelogind is used.  libelogind has a compatible API and provides the
needed facilities.  Ie, policykit is simply built against libelogind
instead of libsystemd.

However, in Debian we cannot just do that because we want to support
both elogind and systemd-logind.  That means we have to pick some
point in the layering to make the either/or switch.

libelogind provides many of the the same symbols as libsystemd: sd_*
functions, basically.  This make sense given that its purpose is to
provide a drop-in replacement for OS's without systemd.  However,
while libelogind is obviously intended to be API-compatible with
libsystemd, it is not realistic to expect it to continue to be
ABI-compatible indefinitely.  (Even though right now I think it
probably is.)

All of this means that libelogind.so and libsystemd.so cannot coexist
within a single executable.

I think would be a very bad idea to have elogind generate a libelogind
package containing a libsystemd.so (so that the switch would be made
by installing only the appropriate runtime library package).

Since policykit does not provide a .so-based plugin interface this
means different sets of policykit binaries are needed.  And the
policykit upstream build system does not contemplate multiple
implementations.

I therefore conclude that the right approach is indeed that proposed
by Mark Hindley:

We should, in Debian, configure and build the whole policykit upstream
source code twice: once against libsystemd and once against
libelogind.

If we make each of these builds produce different binary packages, we
can use Debian's existing dependency mechanisms to arrange that the
right version of policykit gets installed.

Ideally all of these builds would be made out of the same single
policykit source package.

(In principle there might be a risk of entangled transitions but
judging by the existing sonames, ABI bumps in this area are rare.  We
should confirm with elogind upstream that they do take appropriate
care about ABI issues.)


Does this all make sense ?  If so then I will write a message to the
Debian policykit maintainers asking for their opinion in principle,
reusing much of the above text.  I think that is a good idea before
simply sending them the patch.


Regards,
Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.