Changes between Version 1 and Version 2 of PortLoggingProposal

Timestamp:

Oct 5, 2007, 4:06:16 AM (17 years ago)

Author:

jmpalacios (Juan Manuel Palacios)

Comment:

--

PortLoggingProposal

@@ -1 +1 @@
 This proposal aims to add full logging support to the MacPorts infrastructure so that a record of all of the activities of a build run and their results is output upon request to a file writtten in a well known format, like html, xml or yaml, and kept around for later usage, like user <--> port maintainer feedback or posting of the log to a web based form for automated processing of the build information, among many other potential uses.
 
-The primary goal of the proposal is to provide all kinds of accountability while bulding ports in an automated fashion, when there's no one around to keep an eye open and readily figure out 'what went wrong' when an error is encountered. With the code providing this new feature in place, the port(1) command line utility would initialize a log file whenever a non-informational action is requested for a port; that is to say, only actions acting on the port toward building & installing it would append to (or initialize) the log file, whereas informational actions querying the index to provide information to users would not. Logs would be kept on a per port basis most probably inside their corresponding build directories, each accumulating all actions for the corresponding port as they are executed (whether in regular, serial operation manner or if called separately), unless the user explicitly prunes the log and thus forces MacPorts to initialize a new one. A new port(1) command line level action, 'log', would take care of displaying an existing log for port <port> through a terminal pager, 'port log <port>', whereas a new 'clean' subaction (action-flag) would prune it, 'port clean --log <port>', just as the existing '--all' would as well. Informational command line options -v & -d could inform the user where to the log file is being written to upon initialization, and what log is being accessed at read time.
+The primary goal of the proposal is to provide all kinds of accountability while bulding ports in an automated fashion, when there's no one around to keep an eye open and readily figure out 'what went wrong' when an error is encountered. With the code providing this new feature in place, the port(1) command line utility would initialize a log file whenever a non-informational action is requested for a port; that is to say, only actions acting on the port toward building & installing it would append to (or initialize) the log file, whereas informational actions querying the index to provide information to users would not. Logs would be kept on a per port basis most probably inside their corresponding build directories, each accumulating all actions for the corresponding port as they are executed (whether in regular, serial operation manner or if called separately), unless the user explicitly prunes the log and thus forces MacPorts to initialize a new one. A new port(1) command line level action, 'log', would take care of displaying an existing log for port <port> through a terminal pager, 'port log <port>', whereas a new 'clean' subaction (action-flag) would prune it, 'port clean --log <port>', just as the existing '--all' would as well. Informational command line options -v & -d could inform the user where the log file is being written to upon initialization, and what log is being accessed at read time.
 
 The log format itself could be a versioned work in progress we would refine as we work toward polishing the logging feature, governing it by a public specification that defines what metadata we output to the log and how; said specification itself would be governed by us in turn (MacPorts). On the other hand, eligible file formats for the log could be: one record per line plain text with pound sign delimted comments (the logging specification version being one of them); html, with tags delimiting each of the insallation stages; xml, a schema or dtd version defining the logging specification; yaml or others. Well placed code abstractions could buy us some flexibility in separating our own log format specification (what we output and how) from the file level format we choose (plain text, html, xml, etc), and in switching from one to the other should the need ever arise. Two crucial factors in deciding what file level format we end up choosing, however, are the amount of metadata we decide to output to the log (e.g. MacPorts release, host platform, compiler version, requested port, requested action, built with root permissions? etc.) and the flexibility of the chosen file format to append data to an already open file.