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

[Maxime Devos]

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.

signature.asc
Description: This is a digitally signed message part