[RFC] nALFS package log files

Kevin P. Fleming kpfleming at linuxfromscratch.org
Tue Feb 10 20:10:48 PST 2004

James Robertson wrote:

Yow, the lid to Pandora's box blows off with the force of a thousand 
suns never to be seen nor heard from again :-)

> 1./ Are you still looking to use the installwatch lib to get a list of 
> files installed by each package or continue with the double-find method 
> currently used?  What other options do we have?

The double-find method is already gone, that was one of the last things 
that Neven worked on. I don't know the specific reasoning behind the 
removal, but it's gone. Yes eventually we will have some type of 
installwatch functionality.

> 2./ Will nALFS provide a function for someone to parse the logs to see 
> what packages they installed or have been installed by nALFS? 
> Essentially a reporting module.  I see the reporting module as a major 
> value-add feature if we do it.  A person can see what has been 
> installed, find out what package a file is part of with a query, how 
> long a package takes to install, how long all the packages took to 
> install, etc.  I know I would use the heck out of it!

There is already a "P" command inside nALFS that parses the package 
logs, that will be retained, as will its (very basic) uninstall 
functionality. The reporting module, while something I would be happy to 
include in the nALFS tarball, will need to be created by someone else. 
My hope is that creating a well-documented XML log file format will make 
that easy to do in any standard scripting language (both Perl and Python 
can handle XML quite well). The results you are referring to are exactly 
why I want to do this, it can even be extended to some type of 
comparison tool that compares two batches of logs and produces 
time-consumed reports or something even fancier.

> 3./ Are we going to put these logs in a perm location on the file system 
> - for example /var/log/nALFS/ or something to that effect?

They already are put into a packages directory underneath whatever you 
have specified as your alfs_directory. That will not change.

> 4./ What if you re-install a package via nALFS, will it overwrite the 
> old log file or append to show an admin that is has been installed more 
> than once and when?  If it is, can we have nALFS ask to put a comment in 
> as to why it was re-installed? This can help a lot with change 
> management, have the log contain a lot of that info.  How about a 
> <comment> tag period?

The log files will never be overwritten; additional runs of a package's 
profile (same package name) will create additional package_run elements 
in the log file, with all the appropriate content.

> 5./ Will the log DTD be a member of the main DTD?  Does it need 
> documentation (rhetorical q)?

Yes I will create a DTD for it, it will not be part of the main DTD as 
it will never be used for the same files. It will very likely need some 
documentation, although I can't imagine it being extensive.

> 6./ Will the <output> and </output> tags contain both stdout and stderr 
> in the same place or can we split it out to <output fd="stderr"> and 
> <output fd="stdout"> or something?  Probably would help #2 - log parser.

For now (and probably forever) the <output> element will contain all 
output generated by the handlers. I have plans to change the nALFS 
backend to use a pty to grab the system output, which removes the 
possibility of even knowing what was stdout vs. stderr (but improves 
other things).

> 7./ Why not just <package> as opposed to <package_run>?  Seems easier to 
> me.

Because there can be more than one <package_run> for a package, see the 
answer to #4.

> 8./ Why not <command_executed> as opposed to <handler>?  I would like to 
> know what command was passed to the system.  On second thought, I see 
> where <handler> can be useful, but would still like to know the command 
> sent to the shell.

I will probably extend the <handler> element to log what the handler 
actually did, but not not until after the XML parser is rewritten, which 
won't happen before 1.3 is released.

> 9./ Is <stage> a regurtigation of what is in the profile for <stage 
> name="">?


> 10./ Do we want to log the md5 and tarball used?

(See #8) When the handlers can log more details, sure the <unpack> 
element could do that.

> 11./ If we log the source location, how about destination 
> (--prefix=/foo/bar)?

That would be difficult, as none of the elements currently have any way 
to know that (--prefix is just a generic <param> supplied to 
<configure>). It can be deduced from the installed files list, which is 
probably enough, and if the handler echos the configure command into the 
log file it will be there too.

> 12./ I am confused on where <files> comes in.  I would think that it 
> would be the last set of tags for a <package_run></package_run>.  Every 
> "kit" should include it, even if no files where written. The tags would 
> contain a "No files installed" or something message.  Would it handle 
> changed/modified files?  How do we differentiate between "installed" or 
> "changed"?  I would want to know this.  What package and/or stage "owns" 
> a file, but also know what package and/or stages modify an existing file

<files> will not appear if installed-file tracking is disabled 
completely. Otherwise it will be there, possibly empty. The extension of 
this list for showing installed vs. changed will have to wait until 
installwatch or something similar is in place. The syntax I proposed may 
have to be changed though, to not put the raw paths inside <files> but 
instead add a <file> element for each one that could eventually hold 
attributes that signify what happened to it.

> 13./ If we end or have a <end status="error"> where is the error message 
> placed?

In the <output> element, unless you've disabled it. If you have, you get 
what you asked for. Actually, that's not quite true, any messages 
generated by the handlers themselves will always appear in the <handler> 
element somewhere, I just haven't decided upon a syntax for them yet.

More information about the alfs-discuss mailing list