nALFS CVS status (phase 3)
Kevin P. Fleming
kpfleming at linuxfromscratch.org
Wed Mar 31 05:49:31 PST 2004
>>>- how about to add an entity to the books to identify the type of the
>>>book? i.e. booktype=<lfs|blfs|hlfs|...>
>>The profile name itself should be enough.
> and when you want to create that profile-name?
I was referring to the filename of the XML file containing the profile.
Were you thinking of something else?
> none at all! Sorry, I didn't meant in the profile, but in the book (i.e.
> chapter 6), so the information is all together.
> Having that in the profile or elsewhere is lot of additional work for support.
> I think, having such an info in the book, could be less maintenance.
This would be better discussed on lfs-dev then, and as best I can tell
there are already admonitions in the book text for the "important"
packages to tell the user to not mess with optimization flags for that
package. Are there others that you have had problems with that the book
does not mention?
> :) You know, I'm stil working on generating profiles, so I toggle a lot
> between nALFS and my script.
> Meanwhile I changed to dtd 3.2 - hope the feedback is useful anyway.
> May be an attached xml-file is 'suspicious', so here is the fragment:
OK, this is a simple problem, there are a lot of handlers that aren't
marked to allow comments inside them. I need to correct that, comments
should be allowed just about anywhere.
> - what do you think about an entry in .nALFSrc wich toggles the appending/
> resetting of the logfile? When having lots of errors in the logfile, it is
> useful, not to append to the file from last run.
> OK, it's useful only for testing ...
There is already an option to turn on/on the logging of the status
window to the log_file; resetting the log_file is not currently
implemented, but something like that could be done fairly easily.
> - the reloading of a profile does not work
Correct, this is on my list of things to fix in the next week or so. At
the moment there are subtle memory corruption issues that need to be
> - is it possible, to do something like make does:
> copy a file only if the target does not exists?
Not at this time, no, because you can specify anything you want to the
<copy> element, including wildcards and other shell-specific grammar.
nALFS can't check all the possible destinations to see if they exist.
Once the conditional execution stuff is all working properly (actually
enough is working now for this functionality), you can do this:
> - with 3.2 dtd a file is mandatory for remove. What is the right way with that
> syntax to remove a directory (rm -rf dirname) ?
You can supply any path you like to <file> for <remove>, even if it is a
directory path. If that's not clear enough maybe we should discuss
whether the syntax should be changed for <remove> to make it more
obvious. If you think that's needed, please start a new thread for that
discussion as most list members are probably not reading this one :-)
More information about the alfs-discuss