> > I might as well do it now along with everything else. > I suggest that you start by identifying which modules you want to > install (i.e. treat them like everything else in the book - some > final package has required and optional dependencies.
I'm still building it up stepwise at this stage. (I'm using it right now because Firefox was on my first-priority path, but this is more of a "test-drive". It's not a finished "release candidate" yet at all.) It hasn't come to operational requirements. But I don't want to have to address those piecemeal later. There are a lot of Perl modules dealing with XML, for one example, and there are an increasing number of packages using XML. I'd prefer to build modules now that are *likely* to to be used as I continue building. On the other hand, it seems like more development is being done with Python than Perl of late. > the presence of a sendmail program is often checked for, but in my > case it comes from postfix). Exim here. > Note that km_build is one of my functions to detect if the step > (usually a package) has been already built, and if not it will run > what I call the client script. And it will stop if the client I was thinking that extracting the order in which cpan builds things would accomplish that. Of course, that's "cheating" in a sense. -- Paul Rogers [email protected] Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://www.fastmail.com - A fast, anti-spam email service. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
