| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
On 9/2/25 4:08 PM, Rahul Chandra ([email protected] via blfs-dev Mailing List) wrote:
> On Mon, Sep 1, 2025 at 4:41 PM "Zeckma"
> <[email protected]> wrote:
[snip]
> 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."
I like this. There is nothing wrong with pointing to things outside of BLFS. We do
that all the time with external optional dependencies. Adding a paragraph or two in
a <note> does not increase the maintenance burden.
[snip]
> 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.
Good point.
>> 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.
I'm not opposed to this, but am concerned if the timing of updates of the different
packages would be a problem.
>> 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.
It seems to me that this falls into the realm of supporting packages not in BLFS. If
it is needed for GLFS, then it should be there. If something in BLFS does develop
the need, than by all means we should add it, but until then, let's not.
-- Bruce
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page