On 05/30/2011 08:19 PM, Bruce Dubbs wrote: > Dan Nicholson wrote: >> On Mon, May 30, 2011 at 12:55 PM, Bruce Dubbs<[email protected]> wrote: >>> DJ Lucas wrote: >>>> On 05/30/2011 12:34 PM, Bruce Dubbs wrote: >>>>> In the latest svn, the bootscripts are lfs-bootscripts-20110424. >>>>> >>>>> I get an error: Â make[1]: /usr/lib/lsb/install_initd: Command not found >>>>> >>>>> This was identified a week ago by xinglp, but I don't see a fix. >>>>> >>>>> Â Â -- Bruce >>>> Either need to roll back the inadvertent commit to the bootscripts >>>> tarball job or move forward with the patch I sent in. Let me know if I >>>> should do this. >>> I'd appreciate it if you could do a revert.
Done. >>> Â I took a look at the patch >>> and it installs initd-tools as yet another package. Â I looked at the >>> source to initd-tools and I don't understand why we need a C program to >>> do that. Â It could be done in a shell script. That would require some >>> effort to create, but would be much easier to maintain. >>> >>> Perhaps I can try writing the script after the middle of next month. Â We >>> have a big deadline coming up. Â After that, Â I think I've earned about a >>> year of comp time. >> Try writing as a shell script, Bruce. DJ did before and found that my >> C version was much, much faster. Parsing the dependencies and building >> a tree in an interpreted language with no data structures is a >> nightmare. In C it's a linked list of structs. Just my opinion, >> though. > 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. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
