Nathan Coulson wrote: > To sum it up, I would hate to lose X. It is a major part of BLFS, and one > I have spent a lot of time with. > Firefox/Thunderbird/Java/Apache/PHP/MySQL/OpenOffice[now LibreOffice]/Cups > are the first things I build when I startup a system. > > no personal use for KDE3/KDE4, but KDE3 has a minimal footprint maintenance > wise. KDE4, I have been dreaming of it being part of the book forever so I > am glad to see it [just wish I liked it... fluxbox spoiled me]. no use for > gnome2, but people are maintaining it, and seems to be needed for a few of > the applications.
I think the impetus for this discussion is really "How do we issue a release version of BLFS with limited editor resources?" I don't think anyone proposed removing X or KDE or Gnome completely. Splitting up into multiple books is a reasonable proposal. There may be a way to create multiple books that pick and choose what would be included. The only real problem with that is fixing the xref statements to other parts of the book not in the subset being considered. My thought of splitting the book is those things that need X and those that don't. For instance jpeg and png, while providing for the manipulation of images, do not need X. The tricky packages are things like ImageMagick that can be built without X, but uses it if present. I did need these packages recently for a web server where we were creating images, but where the display was only via a remote graphical browser. Perhaps placing those packages that *require* X in a GUI-BLFS and the others in a NON-GUI-BLFS would be resoanble. (Note, I don't really care for those names, but the names present the concept.) Perhaps it should be 'BLFS - Volume 1' and 'BLFS - Volume II'. There still would need to be references from Vol I to Vol II and vice versa. > Been thinking I should throw my hat into the ring, I've spent the time & > research on updating my personal build scripts to work, but I have never > sat down & researched the XML. XML is not hard in principle. It's really no harder than HTML -- tags and attributes for a particular application. In this case those tags are defined in docbook. A medium problem is debugging errors when doing a test build. The solution there is not to make too many changes at once. On my system, it takes about 2 minutes to do a test build. The hard part of XML is doing the XSLT code. We were fortunate to have had Manuel do the critical parts early on and we've been in the fortunate position of not needing much change to that for the last few years. I've been able to pick up a little XSLT to make minor changes when needed. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
