On Sat, Jul 30, 2011 at 6:22 PM, Rob Landley <r...@landley.net> wrote: > So I grabbed the SVN, which produced nothing interesting in the top > level directory, guessed I wanted "book", there was a readme in there, > told me I could run make, and I did. It sat there for three minutes > "validating the book" before I gave up and killed it. Looked at the > readme some more, it said I could do "make nochunks", which i did, and > it started validating xml again. Killed it, opened up the makefile, > searched for nochunks, it didn't have an obvious dependency on > validating (oh great, another crawling makefile horror) searched for the > "Validating the book" string, put an echo in front of its targets, that > did nothing, searched again and found a SECOND instance of this, put an > echo in front of THOSE targets, and then make nochunks died with: > > Generating profiled XML for XHTML... > warning: failed to load external entity "tmp/blfs-full.xml" > unable to parse tmp/blfs-full.xml > make: *** [tmp/blfs-html.xml] Error 6 > > That was about the limit of my interest for the moment. I have a guess > why you have no new developers. >
Not everyone who uses or develops against BLFS automates it. Of course some of us don't have time to sift through the plethora of packages either. In my case, the items I use from BLFS work just fine, so there's no need for help in developing those sections. If one of them broke then I'd definitely speak up. I wish I had the time to build more sections to help with this project. I can see that happening in the near future fortunately. I'm interested in seeing this project continue. I liked the suggestion in this long chain of emails about dividing the book up, but at the same time I can see why it could complicate development even further. Let's say we split it up four ways, there's now four times the number of mailing lists to watch, and that's not even talking about the book directly. Extra overhead with too few developers, editors and maintainers isn't going to help matters. Perhaps what is needed is a way to easily determine what is broken and what is not. There seems to be a split consensus of whether releases are necessary or not. If BLFS was to do a release in the near future, I think the easiest way would be to mark packages with a category tag of some sort indicating the status of that particular segment of the project. As purely part of the suggestion, here's three categories I think would be useful: * Stabilized (tested against the current LFS) * Unstable (as in no longer builds against current LFS) * Development (as in new to the book and YMMV) A known stable book could be produced, but unfortunately be short a few packages. Then for the adventurous, there would be a clear distinction to the readers of the development book as to what is out of date and needs work in order to make it into the next release. Packages that are consistently ill-maintained will be much more apparent to readers and maintainers alike. This is just a suggested solution to the problem of developing and maintaining the project. I'm not advocating that a release is necessary. I just think that what is ill-maintained should stick out more. This helps both the people who don't want to work with stuff that isn't stable, and those who are willing to tinker but have no idea where to start placing their effort. It has the added side effect that a working copy could be rendered out of what is known to be good. On the same vein, but not really having to do with the suggestion above, I do have a question directed to the maintainers. I know a lot of the packages have three types of dependencies listed: Required, Recommended and Optional. Are all of these conditions expected to be tested to consider it stable? I would imagine that the Required and Recommended are, but the Optional is just listed for reader convenience under the assumption that they have never worked with the package before. Jonathan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
