Hi, Back on Dec 15, Ag. D. Hatzimanikas wrote:
>/ Thats why I said we should try, either to make the Book more compact, follow />/ a linear build and towards a direction e.g, Gnome or else we should />/ try to find people that will maintain specific programs that they care />/ and use. / Has any thought been given to adopting, for lack of a better term, a "ubuntu" approach, i.e., having a Gnome BLFS (GLFS?), KDE BLFS (KLFS?) and Server BLFS (SLFS?)? I presume each editor is more comfortable with one vs. another and that very few build and use Gnome and KDE together on a regular basis. It also seems to me that a server BLFS book would be much simpler to keep up to date, since it wouldn't have to include any of the X/Gnome/KDE/Multimedia sections. There are of course issues of overlap and redundancy, but each "book" would be much more focused, and common areas could of course be shared and improved concurrently. Later, Alexander E. Patrakov wrote: >/ IMHO, version numbers and releases are not a thing that one should />/ look at. Everyone is going to try the book instructions on the latest />/ upstream version./ Is that a realistic expectation? I would've thought that until someone has a couple of LFS/BLFS builds under their belt they'd stick with the documented version, unless they had a specific interest in a given package(s). On another subject, I appreciate the BLFS style of having the download information on the package page vs. the LFS "all packages" approach, but I usually like to check the package project home page (provided by LFS) and/or a Wikipedia page to help me decide whether I want to build it or not, or as a handy reference for associated mailing lists, bug tracking, etc. I'll be glad to contribute this information if people think this is useful. Joe -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
