[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 
this week).

> 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.

> <package>
>     <name>foo</name>
>     <version>95</version>
> ......
> </package>
> 
> and repeat
> 
> We can't do that?  I must be missing something.

My original syntax was wrong, it will be:

<package_log>
   <name>foo</name>
   <package_run>
     <version>xyz</version>
     ...
   </package_run>
   <package_run>
     <version>xyz</version>
     ...
   </package_run>
</package_log>

> 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 
> grep.

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 mailing list