Splitting LFS and BLFS Bootscripts [Was Re: Package updates for 5.1 release]

DJ Lucas dj at lucasit.com
Wed May 12 16:23:06 PDT 2004


Tushar Teredesai wrote:
> Archaic wrote:
> 
> 
>>Nathan and Jeremy did wonderful work on updating the bootscripts and
>>giving it new functionality. 

Much agreed!

>>With all this functionality, is there not a
>>method of splitting the LFS from the BLFS? This looks like it could be
>>an eternally nagging problem. I see both sides and have no real affinity
>>for either. LFS is in freeze. BLFS wants to be consistant. Splitting the
>>scripts seems the most likely long-term solution. Afterall, no matter
>>how the scripts are packaged, BLFS scripts have always relied on LFS,
>>but we never had to bundle them together before and things worked out
>>okay.
>> 
>>
> 
> I was going to propose to move the blfs portion of the scripts over to 
> BLFS cvs. Then the BLFS editors could edit the scripts as and when the 
> book is changed and also make a release as and when needed.
> 

Personally, I don't like that idea.  Bootscripts, wether for lfs or blfs 
should be handled by the same team so that the checks and ballances are 
consistant (one troublesome part in particular is 'no bashisms').

> Another thing I was going to propose is to use the same versioning 
> scheme for lfs-bootscripts as the book. That is LFS-6.0 would use 
> lfs-bootscripts-6.0 and BLFS-6.0 would use blfs-bootscripts-6.0.
> 

Is it too late to split them for 5.1?  I mean, it's just a new tarball 
for lfs-bootscripts, rip out the blfs directory, and kill all the blfs 
make targets in the Makefile right?  This could be done correctly in a 
matter of minutes.  The cvs work is obviously more than this, but that 
can be handled after the split.  The alternative is BLFS could just use 
a newer set of bootscripts than LFS, stick to the 2.0.6 branch with an 
extraversion (2.0.6.1...).  Being that BLFS should lag just a little 
behind LFS on release, I don't see that as a problem either.

-- DJ Lucas




More information about the lfs-dev mailing list