Robert Xu wrote:
>> I'm risking insulting people, but it seems to me that the alfs,
>> clfs, hlfs, and livecd projects are basically dead.
I think the better term is dormant. If there is interest, I'm sure
someone will update.
>> From a previous discussion here, I got the impression the people
>> use their own scripts to automate lfs.
That's part of the learning process.
> ALFS doesn't work for me sometimes because there's something broken in
> BLFS that it would fail right away and there would be no way possible
> to resume. I would have to restart all over.
jhalfs works for LFS, but I use scripts for BLFS. Automating BLFS is
very difficult because of the need to be able to do individual packages.
>> blfs support seems to be active, though development seems erratic at
>> best.
That's a good observation.
> Gah, it probably takes a long time to find all the updates... It'd be
> nice if we had software that could find updates and alert blfs-dev.
Even such a script appeared, we would need a lot more volunteers to make
changes thatn we have now.
>> 1. There is no way to get back to the home page
>> ('http://community.linuxfromscratch.org/')
>> from any of the other pages.
>
> Heh, same as trac.
Thee are two 'home' pages. The trac wiki page and the main LFS html
bases site. Trac is really a developer tool and not so much for
non-developers. The mailing lists are the primary way for ysers to
interact, but there is an irc channel too.
>> 2. Building the first time, following the book. The book is
>> (mostly) well written and clear. This step can be improved by
>> looking at points people repeatedly ask about on the support list.
>> Issues which come to mind are configuring the kernel and grub.
I've written hinst for both of these.
>> 4.b. Grammar or clarity issues in the text. For some reason these
>> usually end up as a flame war. My opinion on these clarity cases,
>> is that if someone says it is unclear to them, they should be
>> believed, and the other side should at least understand what can be
>> unclear (possibly only for foreigners), even if they choose not to
>> fix it.
Grammar or clarity issues are often a one person opinion. If there are
clear errors, they generally get fixed immediately and there is no
discussion.
The difference between LFS and other projects is that we do respond to
these comments. I've seen a lot of projects where users are ignored.
>> 4.e. Suggest "major" design updates for the book. The response is
>> usually that the book isn't intended for this, without leaving room
>> for discussion.
Many times the suggestion is that *we* change the book. No patches are
submitted. No hints submitted. Most major suggestions require a lot of
work by someone other than the suggester. Many suggestions make LFS
more complicated. It's already complicated. Adding complexity like
multi-lib or package management detracts from the purpose of building a
working system, especaially for first time builders.
>> Finally, what do I think should be done? First, LFS needs to choose
>> its direction.
We have. We keep the book up to date but only add packages if needed
for other critical packages. We recently added gmp, mpfr, and mpc
because they are required by gcc.
This is the core. It does not cover everything, even for the packages
in the book. For instance we only build c and c++ from gcc and do not
build the graphical part of vim (which requires X).
>> I suggest releasing a stable "package update" release regularly, say
>> once a month.
We make a new release at six month intervals. September and March.
-dev gets updated pretty much as packages are released. In a recent
case, we had a problem with the kernel in -dev and had to find a fix
that took a couple of months. We would not have released the book with
gcc-4.5 with the bug found (eventually) in the kernel.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
