On Sunday 24 February 2008 09:02:11 pm Joe wrote: > 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. > I see pluses and minuses with approaches like these. On one hand, a division of labor like this could help speed up the release process for each section, because you could, say, release a KDE book before Gnome is ready, or vice-versa. On the other hand, I think there could be issues with too much splintering of the dev community.
> 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). > To me, version numbers are very important to have in the book. I would agree with Alexander that people will try the latest versions quite frequently, but blfs should provide known-working versions. Otherwise, you wind up in the same situation as cblfs. While there is a huge number of packages listed in cblfs, mostly the latest releases, I have run into several problems with incompatible versions. > 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. > Agree 100% Robert Daniels -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
