Subject: [bug#74522] [PATCH 21/73] move libgl provider from mesa to libglvnd+mesa

From: The Man <[email-masked]>
Date: Mon, 28 Apr 2025 21:29:19 -0500

grep -Prl "( +|\"|,)(mesa|libglvnd)(\"| |$|\))" ./*.scm | grep -v
"gl.scm" | xargs sed -Ei -e "s/( +|\"|,)(mesa)(\"| |$|\))/\1libgl\3/g"
-e "s/( +|\"|,)(libglvnd)(\"| |$|\))/\1libgl\3/g"
should work well enough as a base to get started. catching the
duplicated replacements can't be too difficult from here. arcan-sdl,
mygui-gl, webrtc-for-telegram-desktop, obs, obs-looking-glass,
looking-glass-client, aquamarine, hyprpaper being the packages i could
find glossing over the diff directly using both mesa and libglvnd
(working with a recent commit).
more effort to come.

On Wed, Apr 2, 2025 at 12:18 AM Maxim Cournoyer
<[email-masked]> wrote:
>
> Hello,
>
> John Kehayias <[email-masked]> writes:
>
> [...]
>
> > Using libglvnd has come up a few times in the past, and unfortunately I
> > don't have a way to test what it may be most helpful for (on foreign
> > distros? or multi-gpu setups?).
> >
> > I had to refresh myself on this long patch series, so my apologies if I
> > missed something, but this looks to be a lot of unnecessary work, no?
> > The "libgl" package and all the dependent input changes is essentially
> > the same as propagating libglvnd from mesa? (I'm not sure about the
> > build changes in there though, didn't look, but I have built mesa with
> > libglvnd before just fine.)
> >
> > In any event, I think the approach discussed way back in
> > <https://issues.guix.gnu.org/49339#8> makes the most sense to me and
> > seems like not as much work:
> >
> > 1. Add libglvnd to Mesa, that enables libglvnd support automatically
> >
> > 2. Propagate libglvnd from Mesa, assuming that fixes many packages;
> > seems like it would be okay as libglvnd isn't something a user would
> > install on its own
> >
> > 3. Fix any packages searching their input's mesa for libraries to search
> > libglvnd, as needed. From the old discussion this seemed to be a
> > manageable (small) number of packages with a straightforward fix.
>
> That would be a good way to minimize the code change, but in my opinion
> is a bit less clean w.r.t. what libglvnd aims to be: an
> abstraction/indirection of the libGL.so implementation.  So if we want
> to truly move to the modern world of where packages get purely linked to
> libglvnd, which in turns dispatches to either mesa or some other
> implementation (configurable at the system level, IIRC), it seems it'd
> be more Guixy to have only libglvnd exposed to builds instead of both
> libglvnd and mesa.
>
> So I think the original patches look fine, but given the mechanical
> changes that should (mostly?) be doable with a sed substitution, I'd
> suggestion doing that in single commit and mentioning which command was
> used in place of the GNU ChangeLog (I had suggested that earlier in
> thread in my reply to patch 20/73).
>
> Would 'The Man' or someone like to tackle that?
>
> You could test this sed command a new branch, and after the automated
> conversion, diffing the new branch against the old one should give no
> difference.
>
> --
> Thanks,
> Maxim