Future of LFS

Bruce Dubbs bruce.dubbs at gmail.com
Sun May 18 21:21:09 PDT 2008

Gerard Beekmans wrote:
>> I'd do the automation in conjunction with the new appendix as that would make 
>> the development easier.
> Great, looking forward to see what a finished product may look like.
> I'd also like to put the following considerations forward.
> Rather than pulling in the bootscripts into the book and document around 
> them, why don't we enhance the bootscripts themselves by adding more 
> comments to them. 

Adding comments was one of my prime desired oucomes of getting them into the 
book.  So people could reference them as they were reviewing the book.  This is 
even more important for BLFS where installing a script may or may not be what 
the user wants, but reviewing them in the book's html or pdf keeps them as an 
inherent part of the book.

> It will make them self-explanatory without going 
> through the trouble of making a duplicate of them inside the LFS book.

I don't think it will end up being that much trouble and it will enhance the 
book.  The user always will have the option of reviewing them with an editor or 
less, etc just as now.

> We can still add extra information to the book (back to chapter 7 as the 
> location for such a thing) without displaying the actual scripts.
> There's just so much source code we could conveniently add to the book 
> for reference. The bootscripts may be a bit of a special case vs an 
> actual program package, but I'm still wondering about whether to do so 
> or not.
> Your proposed method would require us to re-generate a book every time 
> the bootscript package is updated or released. The two are no longer 
> independent like every other package is. Again, granted, the bootscripts 
> package is always more directly tied to LFS than an outside package. It 
> doesn't have to be, though.

The packages are updated a *lot* more frequently than the bootscripts.  Besides, 
the book has to be regenerated anyway for bootscript changes.  The packages.ent 
must be updated with at least the new version, size, and md5 sum.

   -- Bruce

More information about the lfs-dev mailing list