[bug#49339] [PATCH core-updates] gnu: mesa: Update to 21.1.4.

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]

John Kehayias schreef op vr 09-07-2021 om 02:41 [+0000]:
> 
[...]
> > If with this update of mesa, (almost) every package using mesa also needs libglvnd,
> > 
> > then why not add 'libglvnd' to the propagated-inputs mesa, for about the same reasons
> > 
> > that 'atk' has 'glib' in 'propagated-inputs'?
> > 
> > Not sure if the comparison applies though.
> > [...]

> That sounds like a good idea, but I think there may be some kinks to work out. Adding libglvnd to propagated-inputs of Mesa does lead to the successful building of dependents (tested on libepoxy and virtualgl, for example).
> However, libepoxy fails on a test because it doesn't find libGL.
> That is no longer in Mesa's lib but from libglvnd if I'm understanding correctly. May just be a problem with the test since building works (which checks for GL).

Warning: I've no idea how building mesa and libglvnd works,
how linking against mesa and libglvnd works, and how mesa and libglvnd
work, besides ‘you can use the GL_... functions to do GL stuff’.

That said, it appears some package definitions expect "libGL.so" to be in mesa.
(Search for "/lib/libGL" and "lib/libEGL" with 'git grep -F"').
I've found about twenty such occurences, including libepoxy.

So it appears that adding libglvnd to the propagated-inputs and fixing
these twenty package definitions should be doable.

Looking at libepoxy in particular:

             (let ((python (assoc-ref inputs "python"))
                   (mesa (assoc-ref inputs "mesa")))
               (substitute* "src/gen_dispatch.py"
                 (("/usr/bin/env python") python))
               (substitute* (find-files "." "\\.[ch]$")
                 (("libGL.so.1") (string-append mesa "/lib/libGL.so.1"))
                 (("libEGL.so.1") (string-append mesa "/lib/libEGL.so.1")))
               #t))))))

it seems like the test failure isn't a false positive, as libGL.so.1 is searched
for in the wrong location.

> 
> Anyway, perhaps we want to tackle libglvnd separately? I don't think it is specific to the Mesa version change, but more of how we want to handle gl across packages. Still, it will involve changes to how we build Mesa as well as possibly other packages. I'm not sure that the Mesa version change will require other changes in dependent packages (I can only test a few on my own).
> 
> How do you think we should proceed?

I'd suggest adding libglvnd to propagated-inputs
and adjusting the twenty package definitions to refer
to libglvnd, and testing some graphical applications.

"mesa-utils" has "glxdemo" and "glxheads" and has few dependencies,
maybe start with that?

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]