Some packages I'd like to see added

Jeremy Utley jeremy at
Thu Dec 30 20:57:43 PST 2004

Larry Lawrence wrote:

>On Thu, 30 Dec 2004 15:43:17 -0800, Jeremy Utley wrote:
>>Bruce Dubbs wrote:
>>>Jeremy Utley wrote:
>>>>Now, my question to the BLFS developers:  What exactly is BLFS?  Is 
>>>>it hard to install packages, or is it instructions to build packages 
>>>>that make the bare bones LFS system more functional?  At last check, 
>>>>many of the BLFS packages are rather simple builds, but the 
>>>>instructions are still there, so I have always assumed that the goal 
>>>>of BLFS is to provide instructions for a more well-rounded system.  
>>>>If I'm wrong, then I apologize for the noise in suggesting packages, 
>>>>and also recommend removing those packages that are simple cmmi builds.
>>> I hope you are asking this question tongue-in-cheek.  BLFS is 
>>>basically a reference for building packages from an LFS base.  There 
>>>is no rule that says that packages don't go in because they are too 
>>>easy.  My goal is to have most of the most common and most used 
>>>packages in BLFS.  However, the maintenance becomes a great problem 
>>>with the large number of packages already in the book (pushing 400 
>>>now). I have no objection to adding a cmmi package.  In fact they are 
>>>fairly easy and serve to tell users that the package *is* easy to 
>>> I did ask to hold off on new packages until we can get 6.0 out.
>>> I'd also like to note that I don't want BLFS to be limited to build 
>>>instructions.  My goal is to add techniques and references about how 
>>>to configure and use packages effectively and securely.  As many of 
>>>the packages in BLFS have whole books, these will necessarily be limited.
>>> --  Bruce
>>No, Bruce, this wasn't tounge in cheek.  My suggestion was met with 
>>resistance from members of the BLFS development community because the 
>>packages are simple C-M-MI packages.  However, most of what you guys 
>>have in BLFS is the exact same thing, so it made me wonder - what 
>>exactly IS the criteria for getting into BLFS - obviously the criteria 
>>is "useful to a BLFS Editor", since THEY decide what goes in and what 
>The criteria is "maintainable by a BLFS Editor".  The best I can remember,
>the author of Tripwire worked hard to get the package in and did a great
>job of doing it right.  The GCC changes needed on this dormant package
>have to be found and tested. Personally, I have installed it twice and
>stopped using it years ago.  These packages start to consume too much
>time.  Going through a 400 item to-do list, it gets pushed back time and
>again. Bruce's comments last week are they first I've seen on this
>packages for a long, long time.  Obviously, these factors affect what
>editors are willing to work on.
>Yes, additions are what THEY decide as they are making a long term
>commitment for the Editor team. Of the packages you specifically
>mentioned. Fortune never appealed to me (neither as a challenge to install
>or as being useful), although I remember xscreensaver to was quite
>interesting. Gkrellm- I actually drafted this package, but when you factor
>in the Kernel options needed to get sensors working, and how different
>they are for each installation, I decided it was not supportable.  As to
>IRC clients, you have obviously noted that most of the editors have no
>interest in it, I find it impossible to be devoted to editing while
>keeping a chat room discussion on the side (or just monitoring).
>I, personally, have never turned away a submission.  I've returned a few
>with numerous suggestions and all eventually made it into the book. It is
>hard to convey to people that it is extremely easy to get your favorite
>packages in BLFS.  If your not passionate enough about the package to
>write the page and submit it to the editors, why would you (or anyone)
>expect an editor to just do it. The quantity WILL eventually wear an
>editor down.
Well, in my original post, I did volunteer to do the legwork on all 5 of 
these packages, and that includes ongoing maintenance of said packages.  
Adding these packages should not in any way increase the workload of 
BLFS developers, other than applying the occasional patch to the sources 
which I submit.

>My thanks to Randy and Igor for their persistence and stamina and Bruce
>for holding it all together. I understand deeply what they face on a daily
>basis.  I still hope that I can rejoin them at their pace sometime in the
>BLFS IS what the current Editors put into it, technically and emotionally,
>nothing more or less.
And in my opinion this is wrong.  LFS is a community driven project, and 
BLFS is an extention of LFS.  *IF* someone is volunteering to do the 
legwork for the BLFS editors, building the package, checking it all out, 
checking deps, and so forth, then IMHO, it's extremely short-sighted to 
not accept that assistance.



More information about the blfs-dev mailing list