| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
On Tue, 2025-09-02 at 12:33 +0200, Thomas Trepl wrote:
> 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 assume you didn't see the arguments. The arguments are interleaved
with the original text.
> 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).
I'm not forcing them to change anything. But I don't want them forcing
me to install libglvnd.
Why it's wrong to just keep it in GLFS instead of pushing it into BLFS?
> 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?
If a firmware causes trouble and the vendor refuses to fix, I'll just
say building/running LFS with such a firmware is unsupported. Like,
building on a 13900K with buggy microcode will cause permanent hardware
damage so you shouldn't do that, or building on a system with buggy
memory training code in the UEFI will cause "bus error" or "segmentation
fault" building packages like Glibc or GCC and we can do nothing to fix
it. So we don't really support any firmware. It's just most
combinations of firmware don't cause troubles to LFS.
P.S. I'm not against adding fwupd but IMO we should really make it clear
that using it may brick the system if (I'll not say "in case": I don't
think a power outage happening to interrupt a firmware upgrade is so
unlikely) something goes wrong on that page.
But I'd say libglvnd will cause trouble to BLFS. It requires a
completely different graphic software stack layout than what we had.
And if your system has it, you cannot simply get rid of it without
rebuilding a lot of packages (on the contrary if you want to get rid of
the kernel firmware blobs you can simply set CONFIG_FW_LOADER=n and
rebuild the kernel).
And see also https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/222.
> Are they all OS? If so, why don't we build them?
And in most cases they don't even run on the same microprocessor as the
OS.
> 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.
By "not support" I mean if it goes wrong, we can do nothing to help / we
don't want to spend our time to help. Not you cannot use it, nor you
cannot run LFS on it.
I'm building and running LFS on various architectures that the team does
not support anyway. But it does not mean I can push a change not
affecting (or worse, even slowing down) x86 to trunk.
It's like you can connect your computer on an UPS and build LFS on it,
but if your UPS is broken we cannot fix it, or if the software for
controlling the UPS is binary-only and it requires liblber-2.4.so we
won't add OpenLDAP-2.4 into the book (now we have 2.6 which does not
provide the old SONAME).
--
Xi Ruoyao <[email protected]>
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page