| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
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.
-- Bruce
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page