Separate packages for wayland variants

Separate packages for wayland variants

[Jonathan Brielmaier]

Happy new year fellow Guix hackers,

I wonder how we usually deal with package variants for wayland support.

In my case I want to make keepassxc working more nicely on sway. It is
as simple as adding `qtwayland-5` to its input list. Increasing its size
from 1271.8 MiB to 1303.5 MiB.

Indicators for a separate wayland package:
* size gets increased noticeable
* "enabling" wayland breaks X.org
* launching for wayland requires certain environment variables (like
icedove-wayland with MOZ_ENABLE_WAYLAND=1)

Indicators for an all-in-one package:
* size increase relative small
* package works with wayland or X.org
* reducing duplicated build runs and space on disk with almost identical
package variants

Any guidance on this topic is appreciated :)

~Jonathan

Re: Separate packages for wayland variants

[Josselin Poiret]

Hi Jonathan,

Jonathan Brielmaier <jonathan.brielmaier@web.de> writes:

> Happy new year fellow Guix hackers,
>
> I wonder how we usually deal with package variants for wayland support.
>
> In my case I want to make keepassxc working more nicely on sway. It is
> as simple as adding `qtwayland-5` to its input list. Increasing its size
> from 1271.8 MiB to 1303.5 MiB.

My opinion is that those packages should work out of the box on wayland,
and we shouldn't duplicate CI effort by having duplicate packages.

The qt 5 base package should probably include qtwayland-5 somehow,
although I don't really know if that is doable without cycles.  We can
probably have a minimal package and one with qtwayland-5 included. I
don't think it is manageable to add qtwayland-5 to every single
application.

Best,
-- 
Josselin Poiret