Hi,Wlroots is one of the packages for which we need to keep multiple versions around to ensure compatibility with reverse dependencies.
At the moment, we have a wlroots0.17 package [1] (for the few packages that still require it, most notably qtile [2]) and a "regular" wlroots package [3] that currently points to 0.18.
We are evaluating bumping the wlroots package to 0.19, but that requires the introduction of a new wlroots0.18 package to preserve compatibility with reverse dependencies that are not yet compatible with 0.19 (similar to what was done with the wlroots0.17 package).
This method makes new wlroots releases difficult to triage as we have to release both the wlroots package bump and the new wlroots0.18 package at the same time (to avoid breaking changes regarding reverse dependencies) while ensuring that we defined proper "conflicts" to avoid conflicting files issues during upgrade [4] (since we can't control in which order packages will be upgraded on users' system).
For instance, the new wlroots0.18 package would likely need a "conflicts" array that looks like this; in order to avoid files collision with the "regular" wlroots package until it gets updated to 0.19 on users' system, and also to avoid an unexpected conflict with the wlroots0.17 package.
```
conflicts=(
"wlroots<0.19"
"wlroots>=0.18"
)
```
While the above _should_ work, this is a quirky dance that will
eventually get more and more complex over time (e.g. if we have to
accumulate more versions of wlroots in the future).
As such, I would like to switch to a versioned packaging scheme for wlroots. This means dropping the "regular" wlroots package and solely rely on versioned packages like: wlroots0.17, wlroots0.18 & wlroots0.19 (similar to e.g. gtk2, gtk3, gtk4 in a sense). Wlroots already adopted a versioned so/lib naming scheme so there is no file collision between e.g. wlroots0.18 and wlroots0.19 (meaning we won't need the above "conflicts" array dance anymore).
Technically speaking, that means introducing a new wlroots0.18 package that conflicts and replaces the current "regular" wlroots package (to ensure people make the switch without file conflicting issue) and a new wlroots0.19 package. We could then drop the "regular" wlroots package from the repo and keep moving with versioned packages only in the future (e.g. wlroots0.20, wlroots0.21, and so on...). Reverse dependencies can then explicitly point to the version they need (similar to how it's done currently with wlroots0.17).
I'm aware that this may be unconventional regarding how we usually do things in Arch Linux, but I think it's fair to say that current way we have to deal with new wlroots releases is confusing and causes more harm than good. I think the above suggestion is a practical and relevant solution for such specific case.
I created a related task todo list [5] that I will tackle today and put to staging. I intend to leave it in staging for a week or two in order to leave some time for people to react and / or raise any concerns I may have missed about switching to a versioned packaging scheme.
Thanks :) [1] https://archlinux.org/packages/extra/x86_64/wlroots0.17/[2] https://github.com/qtile/qtile/blob/master/docs/manual/wayland.rst?plain=1#L16
[3] https://archlinux.org/packages/extra/x86_64/wlroots/[4] https://gitlab.archlinux.org/archlinux/packaging/packages/wlroots0.17/-/issues/1 [5] https://archlinux.org/todo/switch-to-a-versioned-packaging-scheme-for-wlroots/
-- Regards, Robin Candau / Antiz
OpenPGP_0xFDC3040B92ACA748.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
