svn bootscripts

Bruce Dubbs bruce.dubbs at gmail.com
Tue May 31 08:21:08 PDT 2011


DJ Lucas wrote:
> On 05/30/2011 08:19 PM, Bruce Dubbs wrote:

>> I'll take a look and perhaps I'll come to the same conclusions.  I'm not
>> sure speed is the issue though.
> 
> Oh yes it is! At least in shell with a couple of calls to sed and grep 
> anyhow. :-) I wish I had seen this prior to my other message. Please 
> allow me to save you some time as I speak from experience. Of course, 
> you are certainly welcome to try, but as Dan mentioned above, it was an 
> absolute nightmare in bash, unless I just way over thought it. You are 
> limited to a group of arrays and a rat's nest of complex loops. Dividing 
> into smaller functions and making it more linear might help a little 
> with readability, but I still fear that you'll be dealing with insane 
> loops. Also, in the event of a reciprocal dependency (which is actually 
> an error in the script being installed), the potential for infinite 
> loops exists without error checking on every iteration (which means more 
> calls to grep further slowing things down).
> 
> As for other _interpreted_ languages, I didn't really get far enough 
> with perl to evaluate it, plus I don't actually know it well enough to 
> write a utility that I'd want distributed (it was a learning exercise). 
> Perl certainly provides a more advanced/polished tool set with which to 
> work and seems somewhat of an obvious step WRT LFS (if you really want 
> to use an interpreted language that we already have access to), while 
> Python is the current flavor per Debian (and at least was for other 
> distributions back in 2007/2008) and did seem to work well at that time. 
> Here is the current set of tools that Debian uses:
> 
> http://ftp.debian.org/pool/main/l/lsb/lsb_3.2-27.tar.gz
> 
> I just figured that was immediately out with LFS as it added yet another 
> group of dependencies for which a base package will have to be rebuilt 
> in BLFS (that's two added packages unless the install_initd and 
> remove_initd scripts are included in the bootscripts package). Plus with 
> the exceptionally slow move to Python 3 lingering...it just doesn't seem 
> like a good fit for LFS, at least IMO. With the above said, however, I'm 
> still partial to Dan's tools as I've used them for so long and they seem 
> to work well for our purposes. Another set of eyes on that code would 
> certainly be welcome too I'm sure, and perhaps they can be extended in 
> time to include an lsb-config utility (of course, that could easily be 
> written in shell too, I imagine that wouldn't take more than half an hour).
> 
> Well anyway, there is some food for thought. I hope it helps. See my 
> other message as well if you do decide to proceed with a new tool as 
> there are at least a couple of corner cases that don't immediately 
> spring to mind when doing the outline.

Thanks for the input.  Personally, I like php for scripting, but that 
isn't appropriate for LFS.

Perhaps we are overthinking here.  The trouble I had was using 
install_initd in the lfs-bootscripts Makefile.  If we just get that 
fixed and put Dan's initd-tools in BLFS, it would work out.  After all, 
we don't make LFS completely LSB compatible (e.g. no package manager), 
so postponing initd-tools seems reasonable.

   -- Bruce



More information about the lfs-dev mailing list