FS#69743 - [glew] adopt a standard for "provides" across extra and community for glew and glfw

Attached to Project: Arch Linux
Opened by Paulo Matias (thotypous_) - Tuesday, 23 February 2021, 12:18 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 23 February 2021, 13:50 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Since this request involves both extra and community repositories, I'm posting it in the extra issue tracker.

The community/glew-wayland package used to provide extra/glew. This used to work like a charm, because if a user wanted to use the Wayland implementation instead of the X11 one, they could just install community/glew-wayland.

However, the Wayland implementation of GLEW is not completely compatible with the X11 one. Thus, some people complained that some packages wouldn't work with community/glew-wayland and asked for the "provides" to be removed ( FS#62713 ).

But that solution was really inconvenient. Nowadays, every time there is an extra/glew upgrade or you install a package depending on glew, you need (1) to accept to replace community/glew-wayland with extra/glew (2) to install community/glew-wayland again with `pacman -Sdd glew-wayland`.

Looking at a similar package - glfw - things are done differently. There are two packages, community/glfw-x11 and community/glfw-wayland. Both provide glfw. Packages usually depend on glfw, so that the user can choose their preferred implementation. If some package eventually works only with glfw-x11, or only with glfw-wayland, then it can depend on the specific package.

Therefore, I'd like to make two different proposals:

(1) Rename extra/glew to extra/glew-x11 and make glew-x11 provide glew. Then community/glew-wayland can also provide glew. This has the advantage of adopting the same naming standard which has already worked successfully for glfw. However, it requires some coordination between extra and community repositories; or

(2) Revert  FS#62713  (in that case I should be reporting this issue at the community tracker, but then it'd be out of context). It should not be a surprise to users that two different implementations are not completely compatible. IMHO throwing away dependency management is much more harmful. Anyway, a message could be inserted in the install script to warn users about it.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Tuesday, 23 February 2021, 13:50 GMT
Reason for closing:  Not a bug
Additional comments about closing:  It's no different. Not compatible means not compatible.

Loading...