Hilton Chain writes: > On Wed, 02 Apr 2025 13:18:03 +0800, > Maxim Cournoyer wrote: >> >> Hello, >> >> John Kehayias 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 >> > 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/