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

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.

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.

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.

Again, I'm willing to implement all of these changes. But I want to see
discussion and approval first before I go forward with any of these
changes. Thanks in advance!

[1]: GLES v2 also covers the v3 API.
[2]: https://gitlab.kitware.com/cmake/cmake/-/issues/24019
[3]: https://glfs-book.github.io/slfs/general/glu.html
[4]: https://glfs-book.github.io/glfs/shareddeps/vulkan-sdk.html

- Zeckma

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