Re: Proposals for 12.5/13.0 (libglvnd, Vulkan-SDK, xcb-util-errors)

On Mon, Sep 1, 2025 at 4:41 PM "Zeckma"
<[email protected]> wrote:
>
> Now that 12.4 has released and now begins the new release cycle for
> 12.5/13.0, I'd like to propose a number of ideas of which I'd be
> willing to make a reality that have built up as we were going through
> 12.4's cycle. The main matter of these proposals cover refactors and
> some edits needed as a result of using some out-of-book packages not
> found in BLFS.
>
> My first proposal is adding libglvnd and/or editing some package
> install instructions to accomodate for libglvnd. We currently install
> Mesa's libGL, libGLX, libEGL, and libGLES (v1 + v2[1]). This is fine in
> the case of BLFS as the packages in the book are compiled from source
> and don't have stubborn build systems. The book also assumes the only
> OpenGL and Vulkan drivers will come from Mesa, so installing its
> in-house OpenGL implementations is okay. This causes issues outside of
> BLFS or when libglvnd is already installed. The main issue that often
> gets parroted is that other OpenGL drivers outside of Mesa cannot be
> installed. This can be debatable I feel, but for all intents and
> purposes, installing Mesa's OpenGL implementations will lock a user out
> of installing drivers outside of Mesa. The second issue is that some
> applications that are binary-only, or have no good way to build from
> source without pouring several hours or days to fulfill requirements,
> will often link against libOpenGL, not provided by Mesa, or may link
> against a soname not provided by Mesa. Many AppImages fall into this
> category. I have not tested if this is an issue with Flatpak yet.
> Build systems are also stubborn. OBS Studio and Hyprland require edits
> or patches which require a lot of work to maintain to allow Mesa's
> OpenGL implementations. A common root of that issue is CMake and its
> OpenGL FindPackage file making assumptions. An issue remains upstream
> for years that hasn't got much traction[2]. That's just a small set of
> issues that arise.
>
> I find it a good idea to add libglvnd. From all my testing, BLFS
> wouldn't have to edit many instructions to accomodate adding libglvnd.
> GLU is the main one that would need editing. SLFS covers how to adapt
> for that[3]. Mesa also doesn't need to change that much. The package
> contents will need to be edited mainly. The patch however causes an
> issue with the linking step when linking glxgears and glxinfo. Another
> notable issue is that if libglvnd is not installed, Mesa will install
> its own OpenGL implementations automatically. Thus, an option can be
> added to force configuration to fail if libglvnd is not installed.
> We can also support both, though it would lead to about twice the
> amount of work needed when under a package freeze. The last issue is
> that switching between Mesa libGl to libglvnd libOpenGL on an existing
> system is such a headache that a complete rebuild is preferrable, but
> done once won't have to be done again.
>
> Since BLFS supports Mesa's libGL, it increases the testing burden on
> GLFS and SLFS. However, as long as BLFS supports it, so will GLFS and
> SLFS. The main request here is that packages in BLFS get instructions
> altered to allow for libglvnd so users aren't left scratching their
> head on how to switch to a driver outside of Mesa or why a particular
> component isn't working as expected. At that point though, adding
> libglvnd wouldn't be too big of a deal. Since all that work has been
> done in GLFS and I know how both libglvnd and Mesa work, I can
> implement the necessary changes if approved.
>
> I know a common argument against this is that support for proprietary
> packages will slowly creep into BLFS. However, acting strongly against
> such support locks people out. I found that going in the other
> direction by enabling support only makes things better. I'm happier as
> a result, others are happier, and we all get to use what we want or
> even need to use. libglvnd also is open source, thus its addition won't
> be the beginning of the end. It just gets users closer to what they
> need and may even expect. A last reason to go forward is that even GUIX
> switched to libglvnd years ago. I think it's time for a change, here.
>

IFIRC I brought this up 2 years ago during the 12.0 pre-release. My
consensus is that there are 2 arguments:

1) The no closed-source/proprietary argument -- I think Xi + Thomas
did a good job covering this in the other messages on this thread so I
won't comment much on this.
2) The out-of-scope argument: This was something I believe was
addressed in the previous thread that wasn't brought up here. Nothing
in BLFS strictly needs libglvnd, I know that it can be used for some
things (see typesetting instructions in Ch. 51) but the average user
really won't need it and it's an extra burden to maintain. We axed
gtk2, pkg-config, python2, ada,  and numerous others not because we
didn't want them but because we don't have the capacity to maintain
them to the standards that we want.

In my opinion the best option for both editor maintenance burden and
user education is to put a note on the Mesa page akin to what is in
GLFS now something along the lines of: "There is a newer
implementation of libGL called libglvnd that some  programs outside of
this book need. Most source-built or specifically linux-designed
binary programs will work well as they will attempt to link to Mesa's
newer implementation instead of to the legacy one with extensions. We
recommend trying programs with Mesa first and if they don't work
instructions are provided in GLFS on how to install libglvnd."
Something with a bit more detail can educate people on the history of
these GL implementations and give them the choice on whether they want
to burden themselves with trying it. After all it is "Your Distro,
Your Rules" and a lot of people have the mindset that libglvnd might
as well be closed-source since it's connecting to a stack that is
riddled with closed-source/proprietary elements.

This won't solve the burden of supporting both Mesa + libglvnd in GLFS
but I've never seen something not work with libglvnd that works with
Mesa (it is after all an extension, correct me if I'm wrong), I think
assuming that libglvnd is installed in GLFS (maybe keeping it along
the same lines as a "Recommended" package in BLFS where tests are
always done with it and special exceptions are up to the user/one-off
on the mailing list is a good idea. The very nature of GLFS involves
closed-source programs: like games and launchers, and getting the most
performance out of hardware; so users of that book might be more open
to installing something like libglvnd whereas a Desktop/Programmer
might not be.

> My second proposal is to combine Vulkan-Headers, Vulkan-Loader,
> SPIRV-Headers, SPIRV-Tools, and glslang into one page. GLFS has done
> this under the page name Vulkan-SDK[4]. This had made updating much
> easier. SPIRV-LLVM-Translator however should not get put into the page
> due to extra dependencies, notably LLVM. It is more tied to LLVM than
> the Vulkan SDK version scheme. Either way, I believe doing this will
> just make things easier.
>

Makes sense, Bruce is the final authority on this though.

> My third and last proposal for BLFS in particular is adding
> xcb-util-errors as part of XCB-Utilities. Nothing in BLFS depends on it
> but some Wayland compositors like Hyprland depend on it. It has the
> same install instructions as the rest of XCB-Utilities, so its addition
> would be a good fit.
>

We've had the policy for a while that we remove anything that's only
an 'optional' dependency and not an end package. I know we don't
follow that everywhere but we **usually** do. AFAIK no package in the
book even optionally depends on xcb-util-error so unless we add one of
the aforementioned compositors/window-managers (which I'm all for) we
shouldn't be adding this. See "Going Beyond BLFS" for the rationale
that if you got this far you are armed with the tools and knowledge to
go further.




-- 
Rahul

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page