svn bootscripts

DJ Lucas dj at
Mon May 30 23:21:18 PDT 2011

On 05/30/2011 08:19 PM, Bruce Dubbs wrote:
> Dan Nicholson wrote:
>> On Mon, May 30, 2011 at 12:55 PM, Bruce Dubbs<bruce.dubbs at>  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.

>>> Â 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:

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 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.

More information about the lfs-dev mailing list