GNU bug report logs - #74522
[PATCH 00/73] Moving Guix to libglvnd

Previous Next

Full log

Message #260 received at 74522 <at> debbugs.gnu.org (full text, mbox):

From: Hilton Chain <hako <at> ultrarare.space>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 74522 <at> debbugs.gnu.org, Jonathan Brielmaier <jonathan.brielmaier <at> web.de>,
 André Batista <nandre <at> riseup.net>,
 Mark H Weaver <mhw <at> netris.org>,
 Clément Lassieur <clement <at> lassieur.org>,
 Andreas Enge <andreas <at> enge.fr>, The Man <squishypinkelephant <at> gmail.com>,
 John Kehayias <john.kehayias <at> protonmail.com>
Subject: Re: [bug#74522] [PATCH 21/73] move libgl provider from mesa to
 libglvnd+mesa
Date: Wed, 02 Apr 2025 13:57:14 +0800

On Wed, 02 Apr 2025 13:18:03 +0800,
Maxim Cournoyer wrote:
>
> Hello,
>
> John Kehayias <john.kehayias <at> protonmail.com> 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.

Is there a real use case for libglvnd that doesn't involve a proprietary
graphics driver?  If the answer is no, I don't it worth the new complexity.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.