[RFC] libglvnd: depend on mesa

[st3r4g]

libglvnd doesn't currently install any OpenGL implementation, which makes GL unavailable ootb until the mesa drivers (package mesa-dri) are installed. This happens when installing xorg-minimal (which doesn't pull in the graphics drivers) or a Wayland compositor. Previously, libGL shipped the software rendering driver, so that GL was available (but not optimal), and users were expected to install the mesa-...-dri matching their GPU. Now that all dri drivers are in a single package, it is possible to provide hardware acceleration by default as soon as any program which links with GL is installed.
This PR modifies dependencies so that:
GL app -> libglvnd -> mesa -> mesa-dri

Caveats:

• Due to how xbps-src works (i.e. to avoid loops), a second libglvnd package must be introduced specifically to compile mesa (and kept in sync with the other one)
• xbps-src is not currently trying to build dependencies of subpackages. If it is changed to do so, loops will happen again as libglvnd appears as dependency in some subpackages (maybe those deps can be removed?)
• This will pull in the drivers also when building GL programs in chroot, which is unnecessary. Can it be avoided?

I initially thought about making libglvnd depend on a virtual gl-vendor which would be provided by mesa and nvidia*, but the nvidia packages required non-trivial modifications. Nvidia-only users can uninstall the mesa drivers via ignorepkg anyway.

[st3r4g]

what do you mean exactly by "relying"? I expect that 99% of nvidia users won't care about the wasted space of ~55MB mesa drivers (maybe a bit more due to deps) they don't actually use and they will just leave them installed. The 1% that cares can remove them via ignorepkg. I think that having mesa always installed with libglvnd is a good default and will simplify new installations.

[st3r4g]

I wouldn't say too complex, but I agree that adding the duplicate package is ugly

[ericonr]

Now that we are using libglvnd to build libva without depending on Mesa, I don't think this PR makes sense anymore, does it?

[st3r4g]

Ah yes, this would reintroduce the build cycle. So maybe let's freeze the other PR until we arrive at a decision here.

Anyway, I don't like this PR. The alternative to solve this problem would be to make xbps-src "less strict" with rundeps. I have thought to make it build all rundeps after the dependant instead of before, but that is probably a too drastic change from current behaviour. Or maybe introduce some way to tell it to skip building when it's safe to do so, but it could be misused... what do you think?

[ericonr]

I think either of those would still make bootstrapping pretty complicated. What we'd need is some way of saying that a certain dependency isn't necessary when the package is a makedeps, but when it's installed normally it should be there. This gets hairy pretty quick, unfortunately.

[st3r4g]

I think either of those would still make bootstrapping pretty complicated.

Can you explain why the build-rundep-after-dependant would make bootstrap complicated? I'll link again my proposal #20438 (comment) and following comments.

What we'd need is some way of saying that a certain dependency isn't necessary when the package is a makedeps, but when it's installed normally it should be there. This gets hairy pretty quick, unfortunately.

Isn't that what depends= already is supposed to describe?

[ericonr]

Can you explain why the build-rundep-after-dependant would make bootstrap complicated? I'll link again my proposal #20438 (comment) and following comments.

Re-reading this and that proposal, I'm not sure on which point I disagreed with you.

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.