[pacman-dev] do we need debug in alpm_depcmp?

Dan McGee dpmcgee at gmail.com
Mon Nov 19 13:53:42 EST 2007

On Nov 19, 2007 12:33 PM, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
> > On Nov 19, 2007 6:55 AM, Dan McGee <dpmcgee at gmail.com> wrote:
> > > So in short- submit a patch for *one* feature at a time, and justfiy
> > > it in the commit message. Don't try to sneak things by. I do think
> > > this may be a valid complaint though.
> >
> > Even better? How about something similar to:
> >
> > #ifdef PACMAN_DEBUG
> > #    define DEBUG_LOG(...) _alpm_log(PM_LOG_DEBUG, __VA_ARGS__)
> > #else
> > #    define DEBUG_LOG(x)
> > #endif
> >
> > Then just:
> > s/_alpm_log(PM_LOG_DEBUG,/DEBUG_LOG(/g
> >
> > This way we could simply get rid of all debugging if we wanted to.
> > Then you have both a useful version for debugging, and a "snappy"
> > version that saves 1 or 2 seconds without having to output anything.
> I like this idea, but:
> What about user feedbacks? We will ask them to download a debugging-enabled
> version of pacman?
> Bye, ngaba

Remember we have different kinds of debugging once you start looking
at compile-time parameters. By this I mean PACMAN_DEBUG (either on or
off), and the debug flag (set by --debug). Right now PACMAN_DEBUG is
never used on the libalpm side, which I think is smart.

I think Nagy makes a good point- any debugging we have that is always
compiled in should be O(1) so that we aren't slowing down the program
95% of the time when people aren't using debug.

It may make more sense to reintroduce some sort of handle->debug
option back into libalpm. We could then wrap expensive calls inside an
if(handle->debug), as well as having alpm_log never even calling the
callback function if handle->debug is disabled for PM_LOG_DEBUG

Proposed API change:
alpm_option_debug(int debug); (with a default to off)

Thoughts? This would allow us to always get full debug reports from users.

By the way, I'm not sure I like timestamping the debug logs when
PACMAN_DEBUG is defined- it makes it a lot more of a pain to diff
debug logs from good and bad runs of the same command. I know Nagy
just brought this issue up and was going to implement it before he
knew it was already there. Can someone explain the benefits to me?


More information about the pacman-dev mailing list