Re: [lfs-dev] Moving packages from/to BLFS to/from LFS
| Newsgroups | gmane.linux.lfs.beyond.devel,gmane.linux.lfs.devel |
|---|---|
| Message-ID | <[email protected]> |
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. Rainer -- http://lists.linuxfromscratch.org/sympa/info/blfs-dev Unsubscribe: See the above information page