On Tue, Jan 10, 2006 at 12:53:12PM -0700, Jeremy Herbison wrote: > I doubt this will go over well, but what the heck: > > I understand that Readline was added to LFS because: > 1) Bash can use it vs. its bundled readline functions. > 2) Lots of BLFS packages can link to it. > > I believe PCRE should be added to LFS because: > 1) Grep can use it vs. its bundled regex functions. > 2) Lots of BLFS packages can link to it.
I vote for removing readline. Nothing, per LFS instructions, uses it. That is to say that the built-in readline of bash will be used and no functionality lost. > I, and I'm guessing many others, build PCRE right before Grep in > chapter 6. Yep! But it isn't needed for a basic development system. It is icing on the cake, but even then only for those who know why they might need it. > p.s. Alternatively, could a note similar to Shadow's Cracklib tip > be added to Grep's instructions? That would satisfy the anti-bloat > people (though I wouldn't consider this package bloat at all). That sounds reasonable on the surface with one possible exception: we could put a link like this on nearly every page... Me, personally, I like the educational benefit of learning from experience and developing into a much more advanced user than I was when I first read the book. It shouldn't require explicit paths that one *could* follow. Cracklib, if chosen, is a large improvement for security and as such I believe it warrants special treatment. pcre, though, is not a need and I've not found a BLFS package that required grep linked to pcre, so now we are down to it only benefitting grep and nothing else. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
