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

Am Montag, dem 01.09.2025 um 21:36 -0500 schrieb Bruce Dubbs:
> On 9/1/25 8:16 PM, Xi Ruoyao ([email protected] via blfs-dev Mailing List) wrote:
> > On Mon, 2025-09-01 at 20:40 +0000, Zeckma 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.
> > 
> > I'm still strongly against it.
> > 
> > > 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
> > 
> > We really shouldn't try to support non-cooperate binary packages.  That
> > will just waste the editors' time.
> > 
> > > 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
> > 
> > What's wrong to patch them then if they are already buggy?  I'd say a
> > hard requirement on libglvnd is a bug.
> > 
> > > 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.
> > 
> > Still if it has a bug, it should be fixed, instead of adapting the
> > entire layout of the graphic stack to be "bug compatible."
> > 
> > > 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.
> > 
> > We don't want to deviate from the current approach which *is correct on
> > its own* to support buggy packages, esp. non-cooperating binary
> > packages.
> > 
> > > 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.
> > 
> > Why do we ever need to switch it?
> > 
> > > 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.
> > 
> > Look it won't be really helpful.  In practice a third-party (perhaps
> > even not closed-source) graphic stack does not only contain a GL
> > implementation.  It also contains a third-party kernel module.  So would
> > we also add dkms?  What if we updated the kernel in LFS and then the
> > user complains their dkms module stops to build (or the module isn't
> > even dkms, it's just a binary which only works for one specific kernel
> > version)?  Would we lock the kernel version in LFS then?
> > 
> > Binary-only packages can just break for this or that reason, and in
> > general there's nothing we can do to fix it.  And it's just unfair to
> > adapt open-source components for binary-only packages, esp. in the
> > context of LFS.
> > 
> > > 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.
> > 
> > The thing is *some GPU vendor* is locking them out from using LFS, not
> > us.
> > 
> > > 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
> > 
> > But all its practical uses are for binary packages.  It just sounds like
> > a "GPL condom" is open source so it would be acceptable.
> > 
> > > thus its addition won't
> > > be the beginning of the end. It just gets users closer to what they
> > > need and may even expect.
> > 
> > I don't expect it.
> > 
> > > 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 we don't add libraries that no BLFS packages use as a BLFS
> > package.
> > 
> > If you really need hyperland why not add it too?
> 
> I generally agree with Xi.  That said, we have a few ways to address issues that we 
> do not have as full fledged BLFS entries.  For short items we can ad a paragraph or 
> two in a <note> with links to where a more robust discussion is located.  For longer 
> items we can create a page with information similar to pages in BLFS Chapter 1 and 2 
> or like "Setting Up a Network Firewall" or the font information in Chapter 24.  The 
> third method is to create a hint to go into detail.
> 

I don't.   A simple "I'm strongly against it." is no argument, it says
nothing, it expresses nothing else than an irrelevant personal opinion.
Irrelevant for the LFS/BLFS project. We shouldn't argue that way.
Alternatively, "I'm strongly against it because this and that and blah."
would help others to understand the denial. Just to brush an idea away as
it would be total nonsense is not the kind of communication I expect in the
LFS/BLFS project. It also includes the risk that one assumes that the one
who brushes the idea away has not got it totally and is overtaxed to think
about. We shouldn't do that.

I know, there has been a discussion about the specific GL topic 2yrs(!)
ago. But when referring to it (I assume its done by using 'still') i assume
that hardly one in the public does know about the thread of those days. So
repeating argument in this case wouldn't be redundant but nice to people
who really want to follow the discussion. I do not have any technical input
to provide but I took away that the concerns were that we don't want to
"support" vendors who do not provide their stuff as open source (which is
their f*cking right to do so and we should not overestimate our power in
saying that we have any little option to force a global player to do
anything different as they want: If we do not support stuff of them than WE
do not support it, not THEY do not follow what LFS would like to have).
That leads to the next topic i what to respond here. Of course we do
support non-OS-binaries. What about the kernel firmware-blobs? Are they all
OS? If so, why don't we build them? If we do not support them, we have to
drop the kernel, and with it, the whole project will be gone. If we don't
want to support binaries, we immediately should poweroff the machines and
delete all XMLs we have and quit the registration of the LFS domains. This
argumentation that we don't want to support non-free stuff is a remnand of
the discussions in the late 90th or 2000/2010th were all MS was dead evil
and Linux was all good. Today, we know that neither this nor that is fully
correct.

Next, it is often spoken of "we". We do not support XY, we do this, we
don't do that.  Who is "we"?  I can tell you, not specifying who "we" is
leads to faults you never expect to happen. Our well known cancelor Merkel
has said it back in 2015 in the context of refugees coming to DE in an
extremly high amount. She said "Wir schaffen das", meaning "We'll manage
that". She never specified who "we" is. This failure - believe it or not -
was at the end one of the reasons why we now have strange parties in the
parlament which makes the day-to-day work in the government nearly
impossible. Thats not good for the nation, but some of those just want it
that way. So, who is "we"?

I don't know of a manifest which states that "we" (as editors of B/LFS) do
this or don't do that. There is a "We don't want to deviate from the
current approach which ..." above. Again, who is we? And who has said that
this is the projects approach? Is there something that proves that (maybe
there is, then i just don't know of it) or is that just an assumption which
is made to match personal preferences?
As long as the project doesn't have such guidelines (the Editor's guide
would be a good place for that IMHO), speaking of "we" is isn't correct,
its intrusive to all other editors, it has to be "I". I'd hardly come up
and speak in the name of the whole B/LFS project as such by using "we" - I
am me myself, not the B/LFS project. But when we (as editors) do so, we do
speak in the name of the whole project. My suggestion is to not use "we" in
such contexts - "we" would include me but i definitely do not agree to some
of the statements made.

This might lead to a conflict were one says A and the other says B. The
project lead, here Bruce, or the deputy is the authority who will make a
final decision. That's also true for my proposal of using the kernel-base-
patch-mechanism. He will write a final "go ahead" or a final "No" in the
ticket. My personal likes are not relevant in that case - if my arguments
are good enough to convince him (or the majority of us editors and
therefore he'll use the majority's decision) then its as good as when they
are not and the ticket gets closed with a "won't fix".
What i want to say with this is: Its likely that we, the B/LFS project as
such, needs some kind of guideline which defines the decision strategy in
the B/LFS project *).
Otherwise we'll always run in situation where someone speaks up in the name
of the project but the project itself has not communicated an opinion which
proves that "we". If i can agree to all the topics in those guidelines,
than i can speak as "we", if not, i should not talk in the name of the
project as "we".

Just my 2ct,

-- 
Thomas


*)  We should discuss the topics in such a manifest separately. A few of
them, but definitely not limited to, would be imho:
- What is B/LFS
  Still educational stuff showing how things are done to get a working,
personalized Linux based OS? Customization was the motivation of Gerard,
later it became material for university courses afaik. Or are we working
toward a distro? Or something in between?
- Is B/LFS refusing to use binary objects
  what about firmware, bootstrap binaries for Java, FreePascal, FreeBasic,
gcc-ada, gcc-d, ...?
- B/LFS does not include libs to book if none of the books pkgs do use it
  Why not? As long as someone maintains it? Whats the difference to
applications? I do not use KDE nor GNOME, why are they in the book? Ah,
other people do use it. So, maybe others do use that library?
- B/LFS uses stable versions of packages
  If true, why do we rush behind the socalled stable kernel instead of
using a longterm version which is what can be understood as 'stable'? Is it
about supporting new hardware? Are we in a competition with lets say
ArchLinux to be most-current? Or would a stable line (which is updated from
time to time is something important happened) be enough for showing how
things work? 
- ...
(again, to precise, reword and complete that list, we should open another
thread somewhere else)

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