| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
On Fri, 2025-09-05 at 17:06 -0500, Bruce Dubbs wrote:
> On 9/5/25 4:08 PM, Rainer Fiebig ([email protected] via blfs-dev Mailing List) wrote:
> > Am 05.09.25 um 03:49 schrieb Xi Ruoyao ([email protected] via lfs-dev
> > Mailing List):
> > > On Thu, 2025-09-04 at 22:43 +0200, Thomas Trepl wrote:
> > > > Am Donnerstag, dem 04.09.2025 um 14:54 -0500 schrieb Bruce Dubbs:
> > > > > On 9/4/25 2:39 PM, Thomas Trepl ([email protected] via lfs-dev Mailing
> > > > > List) wrote:
> > > > > > Am Donnerstag, dem 04.09.2025 um 21:07 +0200 schrieb Rainer Fiebig:
> > > > > > > Am 04.09.25 um 21:00 schrieb Thomas Trepl ([email protected]
> > > > > > > via lfs-dev Mailing List):
> > > > > > > > Am Donnerstag, dem 04.09.2025 um 12:30 -0500 schrieb Bruce Dubbs:
> > > > > > > > > I'm removing the discussion to keep this post to a reasonable level. See the previous
> > > > > > > > > posts in the thread to review the context.
> > > > > > > > >
> > > > > > > > That's a pretty good idea - the latest answers do not deserve any further
> > > > > > > > comments.
> > > > > > > Rather arrogant attitude.
> > > > > >
> > > > > > well, we just learned that the classification of a dependency as optional
> > > > > > or recommended depends on the amount of users who want to use the feature.
> > > > > > I do not comment any further to that one. If you think thats arrogant -
> > > > > > then I love to be arrogant^2.
> > > > >
> > > > > As far as I know, we are the only ones that publish lists of recommended and optional
> > > > > dependencies. For instance Arch appears to virtually make all dependencies required.
> > > > >
> > > > > When we say something is recommended or optional, those are always a judgement call.
> > > > > The difference is twofold. If we recommend a dependency, our instructions assume
> > > > > that dependency has been installed and we think the added capabilities for the
> > > > > package are useful.
> > > > >
> > > > > Overall the LFS and BLFS packages and instructions are all recommendations, but we
> > > > > let the user make the final decision. Your Distro. Your Rules.
> > > > >
> > > > As a last comment on this, i citate what has been said:
> > > >
> > > > "It's [bluez/tk on Python] an optional dependency. If we assume the
> > > > majority of the users need that, it should have been a recommended
> > > > dependency."
> > >
> > > Why this is incorrect?
> > >
> > > > and
> > > >
> > > > "And I'd not say "limiting the user's option" is wrong in nature."
> > >
> > > And still why this is incorrect?
>
> > The books should not limit options but offer guidance. These are
> > different concepts and they require different mindsets.
Should we offer guidance about building the system with LLVM in LFS?
Should we offer guidance about building Rustc and building uutils to
replace coreutils in LFS?
Should we offer guidance about building PAM in LFS?
Should we offer guidance about building Gettext with system libxml2 and
libunistring in LFS?
Should we offer guidance about building a NixOS-like system?
Should we offer guidance about 99999 packages in BLFS to make it par
with $SOME_OTHER_DISTRO, or we are limiting users more than
$SOME_OTHER_DISTRO?
Should we offer guidance about enabling more languages for LFS GCC
instead of rebuilding it in BLFS and wasting more time for users program
in other languages? (Yes I just did it but why it's me, a person
talking about "limiting users"? Why didn't the guys with glorious
ideology about "not to limit users" do it??)
Are things like "don't use custom optimization flags" or "don't have
/usr/lib64" those we've added into the book for many years limiting
users?
Look I need something practical because I really work on (B)LFS. I
don't want to, and also cannot do my work only for some random, great or
not ideology. As any technical change on (B)LFS can be labeled as
"limiting the users" (note that even upgrading a package can be labeled
as "preventing the users from the old version") I can only consider
"limiting the users" is not wrong or I cannot do anything.
--
Xi Ruoyao <[email protected]>
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page