[RFC] nALFS package log files
Kevin P. Fleming
kpfleming at linuxfromscratch.org
Tue Feb 10 21:20:38 PST 2004
James Robertson wrote:
> IIRC, neven wanted to go with installwatch. Probably got pulled away
> before he could finish it. Is this going in before or after 1.3?
Definitely after, I see that as 2.0-type material (see earlier messages
> I have not looked at the P option in depth yet. Sorry about that. Is
> uninstall going to be extended? I would think the logs would come in
> real handy here as well as true dependency handling.
It works fairly well now, but it'll never do what a package manager can
do. Certainly it can't undo changed files at all.
> OK, this makes sense, but would require a new installation dependency
> (perl with the xml mod and/or python). Didn't think that this is
> something we would want to add. How hard is it to do in C? I suck at
> C, but hey you have got to learn somewhere! (not volunteering, got
> enough on my plate at the moment.
The XML parsing is easy to do (we use libxml2 for that), the reporting
part is much harder. I suspect that a perl/XML dependency for the log
reporting/analysis tools will not be a problem, they are not necessary
to run nALFS and build systems.
> What other things? Would the log parser have anyway of determining what
> in the log came from stderr as opposed to stdout? Sure would make
> finding stuff easier. What are all the pros - cons on this one?
Changing to using a pty will solve a couple of problems, most notably it
will be possible to redirect input from the status window to commands
that handlers run, because they will think they are attached to a
terminal instead of /dev/null. I'm not saying doing the pty change will
give us that right away, it just makes it possible. I have also seen
rare occurrences where tests in package "make check" scripts fail if
they are not run against what they think is a terminal, this will take
care of that. Downside is all output from the running commands appears
in a single stream, there's no way to separate it out by stream handle.
> and repeat
> We can't do that? I must be missing something.
My original syntax was wrong, it will be:
> OK. What all will the new XML parser do for us?
Reduced memory consumtion, faster profile loading, the handlers will
actually be involved in parsing their elements and the profile can be
completely validated at load time (vs. some parts waiting until run-time
like happens now).
> How about the logger puts a copy of the full command into the log, then
> we can see what <param> as passed to the configure stage with a simple
Something like that would be a good start, yes.
> OK, sounds good. Clearly after 1.3, which means we will want to version
> the log DTD.
I think the initial version will have <file> elements inside <files>,
just no attributes. Future DTDs will just have to have only #IMPLIED
attributes on <file> so they are backwards-compatible.
> I think there needs to be a differentiation between what the handler
> outputs or the app outputs internally and what stderr and stdout puts
> out from the status window. This all comes from what level of logging
> you pick in the rc file.
The output from the handler will go into (probably) <action> elements
under <handler>, whereas the output captured from running commands will
go into <output>. It may even make sense to make <output> a sub-element
of <action>, since that's the only way that type of output can be
created. I'll think on it some more and produce another syntax draft in
a day or two.
More information about the alfs-discuss