Re: [lfs-dev] Moving packages from/to BLFS to/from LFS

Am 06.09.25 um 00:06 schrieb Bruce Dubbs ([email protected]
via blfs-dev Mailing List):
> 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.
> 
> That's a really tricky thing to do.  We can't really offer all options.
> There are just too many.  One goal we really would like to have is to
> foster the ability of users to discover new things for themselves.
> 
> I'll note that by separating options into recommended and optional we
> are offering guidance.
Right - and I'm fine with that.  I also agree that some preselection
must take place.

But there's a difference between "limiting user's options" and offering
guidance.  They reflect different approaches.  To me "limiting user's
options" has a very unsympathetic, somehow patronizing or dictatorial
connotation that I was immediately at odds with.  And I think it would
be inconsistent with the spirit of the books ("Your distro - Your
rules") which let the user have the driver's seat and leave choices to
him/her.

But perhaps it was just unfortunate wording.

Rainer

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