As a long time reader/builder of LFS, since version 6.1, I have only seen packages get into the LFS book that are more of a necessity for the base system because of updates to other base LFS packages, and not for the expanded system which is left on BLFS. I concur with Kevin, I do believe that the LFS base should be as minimal in size and scope to make the system work. Especially because some of the users are going with LFS to make a light weight system for IOT or with older hardware. Or, their goal is the pure learning experience, and part of that experience is re-compiling LFS packages to satisfy BLFS dependencies.
I wouldn't recommend pcre in the LFS system. Kling On Fri, Jun 7, 2019 at 3:16 AM Kevin Buckley via lfs-dev < [email protected]> wrote: > On Wed, 5 Jun 2019 at 02:54, Bruce Dubbs via lfs-dev > <[email protected]> wrote: > > > > I am thinking about moving pcre from BLFS to LFS. The latest less now > > supports pcre and pcre2 and grep also supports pcre. It should be > > pretty stand alone as the only dependency is (optionally) valgrind. > > > > If added, I would place it in Chapter 6 just before grep. > > > > There are 19 references to pcre in BLFS (and 6 to pcre2). > > > > What do you think? > > As I'm someone who already takes packages OUT of the LFS Book > when deploying my base system, it will come as no surprise to hear that > I wouldn't favour any more "Chapter 6 creep" - though I say that as > someone who never took BDB out of LFS when it left. > > Having said that, I do think the idea behind the proposed addition does > suggest that there might be a need, within the BLFS book, to have a > section explictly detailing the recompilation of packges from the LFS > Book. > > I'm aware that at certain points in the LFS Book, reference is made > to a corresponding packge entry in the BLFS Book that adds optional > funtionality, but there isn't a deciated section on say, "Adding extra > funtionality to the LFS packages", where, in ths case, instructions for > recompiling Grep against BLFS packages could be laid out. > > Of course, the more thematic nature of BLFS means that recompilations > of LFS packages can end up scattered across various sections (eg, > Shadow comes under the BLFS Security section because the added > functionality is security-related) so perhaps a dedicated section would > not fit the bill, if that "themeing" is to be maintained. > > I should also point out that I have toyed with the idea of having an > "LFS Boxed Set", where Volume 1 was LFS as is now, Volume 2 > would be BLFS as is, along with a Volume 3, that replaced the thematic > nature of BLFS with a set of Chapters or Sections designed to give you > one "major end Package" plus all the package dependenciess you would > need to deploy it. > > Not clear to me that the XML sources (LFS sources would then be within > the one source "tree/repo") could be used at multiple places within such > a "multi-volume LFS", but it is an idea that I've thought about if not > actually > explored. > > Just my thr'pen'th, > Kevin > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page
-- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
