2009/7/18 Randy McMurchy <[email protected]>: > > What are our realistic choices? > I'm
As my initial suggestion: 1. Give up. Point people to cblfs, or change the blfs wiki so that anyone can post again. [ not my preferred solution, but 2. Consider branching a 6.4 version (following Ag's suggestion to branch each time there is an LFS release) 3. Follow LFS-svn. Inevitably, this means some packages are out of date. In some ways, that would be "going back to our roots" in the early days of BLFS. I note that you mentioned spending 8 hours a day on BLFS in the past, I think for many of us, what you contributed would have taken a bigger commitment than that, so we aren't going to get close to what was done in the past. Further thoughts - If we branch for a release, perhaps each package in that branch should include a status line on its page - I'm thinking of things like "doesn't build", "seems ok", and "untested". Probably other variations too. That might indicate things which ought to be dropped before the branch gets to a release (if it does). I also remember that I was trying to keep my 6.3 system usable, but eventually it got too old (specifically, firefox2 was EOL'd and ff3 needed newer versions of gtk, glib, etc). To me, that says that if we can't release everything, we ought to release the bits which are ok. I'll follow up with a proposal for BLFS-6.4 ĸen -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
