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

Previous Next

Full log

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

From: Z572 <zhengjunjie <at> iscas.ac.cn>
To: Hilton Chain <hako <at> ultrarare.space>
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>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>,
 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 14:45:21 +0800

[Message part 1 (text/plain, inline)]

Hilton Chain <hako <at> ultrarare.space> writes:

> 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.

I think one use case is to be able to use different versions of mesa,
for example archlinux has the mesa-amber[1] package to support classic
OpenGL (non-Gallium3D) drivers

and test using newer versions of mesa.

[1] https://archlinux.org/packages/extra/x86_64/mesa-amber/

[signature.asc (application/pgp-signature, inline)]

Previous Next

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