dj at linuxfromscratch.org
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 gmail.com> 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: /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,
> 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 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.
More information about the lfs-dev