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:
> 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.
More information about the lfs-dev