On 5/25/10, Bryan Kadzban <br...@kadzban.is-a-geek.net> wrote: > [snip] >> Until such time as a package that an LFS system requires cannot >> itself function without parsing XML, then there's seemingly no need >> for utiliites that handle XML to be in the LFS system. > [snip] > to suppress the failure ourselves, let's do it, and note that rebuilding > the package when libxml2/expat is available will enable extra > functionality. Or something like that. > >
Yes, I think something like that. I'll throw another hat into this ring. I just don't like the idea of a package moving from BLFS to LFS and back again next time. I think if it moves, it stays. The best LFS is as straightforward and consistent as possible for all. It should also be as consistent as possible from release to release. The extra functionalities should really be in BLFS and LFS could contain an appendix with information (perhaps instruction pages or reference to BLFS) for adding these functionalities for those who want to build them while building LFS. The actual package in question might just refer to the section in that appendix. Let's not forget that shadow is in BLFS because someone might want to implement PAM or CrackLib. Most will not want to be bothered with these under current thinking. But for those that do, they might be afforded an opportunity to build them along with LFS. I don't know how many want PAM or Glade, but why not spare those that don't, and provide a reference to info for those that do. If not having it throws a test error, then provie some way to handle that if possible. Especially if it is safe to just say "ignore this test error". On the other hand, if expat (or libxml) needs to be in LFS, then that is where it needs to be, and no harm done. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
