Jeremy Huntwork wrote these words on 01/05/06 10:08 CST: > I understood what Bruce was asking just fine. Because there is likely to > be a great deal more work, it makes sense to re-evaluate how BLFS is > structured and organized in general.
Oh. I didn't see it as "a great deal more work". Care to expand on that? Where do you see this? You mean adding a couple of dependency packages? That is trivial. What Bruce is asking about is the i18n and multilib issues. Things that the BLFS Editors aren't really qualified to write about. Additionally, I'm with Alexander on the suggestion about removing stuff that is CMMI. I think it should stay. These packages aren't the ones that are any trouble at all. And the dependencies, descriptions, and URLs is what is important. To me, anyway. Dependencies is a no-brainer. Gotta have 'em. This is the single most important thing in the BLFS BOOK to me. And the URLs are important too. I remember just starting out with LFS, way back before I became an Editor. I was looking at the package's home web site for updates, even though the book specifies a particular version. I'd bet many do this. And the biggest source of frustration to me, was the non-BLFS packages and not knowing their URL to check for updates. Googling gets old. (I've started putting the URLs in a comment at the top of my non-BLFS build scripts for this very reason.) So, in summary, to many folks it is not the instructions themselves which are so valuable. It is the whole package: description, URLs, dependencies, and of course the instructions and configuration items. The whole package is what to me, makes BLFS so great. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 10:07:00 up 102 days, 19:31, 3 users, load average: 1.31, 0.87, 0.45 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
