polkit-1 for elogind

[Andreas Messer]

On Wed, Nov 21, 2018 at 09:32:08PM +0000, Ian Jackson wrote:
> Ian Jackson writes ("Re: polkit-1 for elogind"):
> > I am looking at this now.  I will write up what I think I have
> > discovered.
> [...] 
> 
> 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.

In Devuan we have at the moment two variants of Polkit: One built against
libelogind and another built upon consolekit (different api).

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

Actually we were facing the same problem. Initially I also were
to build polkit against libsystemd for Devuan - but then i learned
that there was no systemd in Devuan/asccii (just libsystemd)
So there was no need for that since we dont had systemd-logind
available.
 
> 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.)

Also, libelogind does not implement all symbols of libsystemd
- because elogind is not implementing all functions of systemd ecosystem.
So it can't be a drop in replacment.

> [...]
> 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).
> [...] 
>
> 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.

Well that was the solution we had choosen for Devuan/ascii as well.
However, I'm not really satisfied with it. For me this is only a kind of
"workaround" to make polkit work with elogind and in turn provide main
desktop functionality on elogind using systems. But, there might be other
packages, which use the session management functions provided by
libsystemd or might use it in future maybe. Each of such a package would
require such a treatment then?

Althoug I don't really like it, for me the most sensible, and probably
most maintainable, effort saving way would be to implement kind
of libsystemd shim which glues libsystemd-using applications to a non
systemd system. Besides session management, this shim would also include
other functions - sorry for wording - of the allmighty libsystemd monolith.

> [cut]

cheers,
Andreas

-- 
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20181121/42b95ed0/attachment.sig>