Packaging Request #3153

[nonsystemd] build wlroots against elogind

Anonymous - over 2 years ago - . Updated over 2 years ago.

% Done:



Following the discussion on the forum, in order to be consistent with what is advised upstream, it would be cleaner to build wlroots against elogind in the [nonsystemd] repository.

In this way, the Parabola package would follow upsteam recommendations and, in case of bugs, it would be easier to receive support from them.



Updated by gap over 2 years ago

AFAICT this is a one line patch in the PKGBUILD mentioned in the upstream link.


Updated by bill-auger over 2 years ago

probably, 'sway' would also need to be rebuilt - the artix package has this compile command, different than the arch package:


arch-meson build "$pkgname-$pkgver" -D sd-bus-provider=libsystemd -D werror=false -D b_ndebug=true

arch-meson build "$pkgname-$pkgver" -D sd-bus-provider=libelogind -D werror=false -D b_ndebug=true

note that artix does not define 'logind' or 'logind-provider=elogind'; so it is not obviously necessary - in fact, it may be pointless - the value or use-case of that compile flag is not obvious - the very purpose of 'elogind' is to be a drop-in-replacement for 'libsystemd'; so most programs which expect systemd to be present, will "just work" with elgind, with no effort or advice from the upstream

is there some existing problem which would be solved by adopting this package?

if not, then why would a [nonsystemd] version of wlroots compiled with `-Dlogind-provider=elogind` be preferable?


Updated by Anonymous over 2 years ago

You’re right bill-auger. There is no known evidence that it will make a difference. As stated by gap on the forum, sway is currently working without systemd.

if not, then why would a [nonsystemd] version of wlroots compiled with `-Dlogind-provider=elogind` be preferable?

I’m not well versed enough in package build and systemd/openrc to provide an educated answer. The only answer I can provide is that it would be preferable because upstream recommends it.

As you said, if it doesn’t add any practical difference, then it may be useless.


Updated by gap over 2 years ago

I think it could be an investment, ie. perhaps there are no issues today, as observed so far, but there might be in future that would be avoided down the road if we make an explicitly nonsystemd-compatible package as recommended by upstream in advance, with the extra maintenance burden as the upfront cost.

Will it pay off in the long run?
Who knows?

Also available in: Atom PDF