proposal: new approach

DJ Lucas dj at
Sat Jul 25 06:48:52 PDT 2009

Guy Dalziel wrote:

> I don't consider it that steep, a little bit of testing never hurt
> anyone. The most basic test we do is to make sure that things compile
> together, and we tend to leave things to people who actually use them,
> that way they'll be compiling them anyway. If we had more community
> input then we could have people report to us what works or not, e.g., "I
> use an LFS 6.5 system and Sendmail <whatever version> compiled and works
> fine against Berkeley DB 4.7.25", or, "I use PHP <whatever version> and
> this compiled and worked fine against Berkeley DB 4.7.25." Nobody said
> it all has to be on the head of one editor, and it's a good way to
> involve the community. Tobias has already got this model started by
> saying, "I've used OpenLDAP 2.4.16 for 4 weeks with Berkeley DB 4.7.25
> and I've had no problems". Now perhaps this model isn't suitable right
> _now_ as we're quite far behind, but I certainly think it's worth
> considering.

No, it's not worth's worth doing.  We need a firm plan of
attack and we need it now.  As both you and Randy have already mentioned
in this thread, and others have for countless threads, BLFS is grossly
behind. I've just started over _again_ with the addition of gcc-4.4.1. 
Seeing that gawk has known breakage with some packages, I'm going to
rebuild gawk quick to account for that change as well (I'm sure a full LFS
build will occur by somebody with that change included).

IMO, the book is not completely useless right now, but there is damn well
a lot of breakage and tons of newer packages. If a package works in your
stack, then just do the update and we'll fix what breaks with that update
as it comes up.

We absolutely need a way to track the pages that have been touched by a
quick glance approach. Bruce's idea in the other thread will do the job
perfectly.  I don't know off the top of my head how to accomplish it, but
I know it can be done pretty quickly. Add a "RELEASE" var to the makefile
to ignore the 'class="dev"' parts, and we are good to generate a released
book by 'RELEASE=1 make blfs'.  As far as placement is concerned,
immediately inside the first <sect2> tag looks good to me.

Finally, as we approach a release quality product, anything that hasn't
been checked is considered fat, an abandoned package, and should be
trimmed if nobody steps up to the plate to account for it.  We'll have to
cross that bridge when we get there, however.

Finally, in light of the amount of work needed to be done, current LFS
editors should be given access to BLFS (if they don't have it already). 
Anything that anyone can contribute, after LFS-6.5 is out the door, will
be greatly appreciated.

Accountability:  Once package freeze is in place for LFS-6.5, which I
think will be good once gawk goes in, I have planned for a full Gnome
Desktop that I will use daily.  Seeing as (due to hardware failure) I do
not have a working LFS at all ATM, this will be my first goal.  I believe
I've read previously that Wayne is interested in Gnome as well so he and I
can work together on that one.  In fact, Wayne, if you are anxious to get
going on that, go ahead and take that ticket from me when you are ready to
make commits.  I'll follow behind and provide verification as I pass
through.  Conversely, where do you build X?  I use the /opt/X11 prefix for
it, without the compatibility symlink (/usr/X11R6) and have previously
fixed a few of the configure checks upstream to account for this.

I also need to build a replacement for my server, which for lack of a
better term ATM, is the Linux equivalent of an SBS box, it provides
authentication, web, mail, printing, and samba file services.  With these
two projects in mind, I alone should be able to account for 75+% of the
packages in the book by daily I imagine most of the current
developers can.  Sorry, only minimal help for the KDE guys from me.

Any objections to any of the above?

-- DJ Lucas

This message has been scanned for viruses and
dangerous content, and is believed to be clean.

More information about the blfs-dev mailing list