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