[Aptitude-devel] aptitude now using log4cxx

[Daniel Burrows]

  Several bits of aptitude have well-developed debugging output.  The
first one that springs to mind is the dependency resolver, but there
are some other areas that also are logged up.

  Right now only a few parts of the program have logging, because (to
be honest) it's a pain to insert logging in a way that lets it be turned
on and off.  Control over logging is not fine-grained at all, and you
can't log anywhere but standard output.

  Starting now, this changes.  I've checked in a changeset that adds
liblog4cxx to the list of libraries aptitude links again -- a change
I've been thinking about for a while, but never got around to.  You
can now write logging statements anywhere in aptitude (with the
appropriate #includes of course); by default logging is enabled
system-wide at whatever the default level is, but there aren't any
output objects (so nothing goes anywhere).  I've done a minimal
conversion of the problem resolver's log statements over to log4cxx
as a proof-of-concept; we might end up wanting more granularity there,
but it will be easy enough to push statements into subdomains later.

  I see this mostly as a way to get better debugging, rather than as a
user logging mechanism -- but who knows, maybe users will end up liking
it too.  I propose the following definitions of the levels:

    TRACE -- detailed information about program flow
    DEBUG -- information that's only useful for debugging, but
             not logging every statement.  e.g., the resolver logs
             at this level for each search node, but not for the
             details of how each search node was produced.
    INFO  -- information that could be useful to the user if they're
             trying to understand what's going on (perhaps things like
             "removing foo because nothing requires it"?)
    WARN  -- things that look "weird" but won't cause a fatal error.
             e.g., maybe log at this level if defensive code detects
             something that "should never happen".
    ERROR -- I'm not sure what to do with this.  Probably we can use
             it for things that are *definitely* wrong but recoverable.
             Or we could just ignore it and use WARN/FATAL instead.
    FATAL -- The world just exploded and we're about to blow up the
             program.  Might be useful to have a variant on the
             eassert() macro that does this; or just log exception
             catches at the FATAL error level.

  I wouldn't worry too much about wholesale conversions of existing
code, or about writing up logging statements for existing code.  It
would be a waste of time to stop other work for that (although if
you want to get familiar with part of the code, that would be a way
to do it). Instead, I'd follow the same policy that we use for
refactoring / redesigning code, which is to do it as-needed or
opportunistically. If you need it in order to debug a particular
problem, or if you're working on some code that lacks logging
statements, feel free to add them.  We should probably start
maintaining a central registry of loggers, too -- actually, on that
thought, I'll go create a "loggers.h" so that we put them all in one
place.

  Still TODO: the big one is that we need to read some logging
configuration, probably using PropertyConfigurator.  Ideally there
would be a system-wide config files and a user-level one.  Maybe some
sane fallbacks (logging to /var/log/aptitude-debug as root and
~/.aptitude/debug-log as non-root, for instance).  I'd also like
command-line options to enable or disable logging (e.g.,
"--log-level=info" or "--log-level=aptitude.download:info", maybe
also "--log-file=/tmp/aptitude.log"?).

  log4cxx information is available here:

    http://logging.apache.org/log4cxx/index.html

  Daniel