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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
