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

Nagy Gabor ngaba at bibl.u-szeged.hu
Mon Nov 19 06:11:44 EST 2007

> Yes, I saw that and I answered :
> http://www.archlinux.org/pipermail/pacman-dev/2007-November/010033.html
> For a more realistic usage like -Qt, I couldn't measure any differences.
> It'll probably be easier to see a difference with smoke001, but is that
> really problematic?
> I didn't like that const strings were modified in _alpm_provision_cmp, so I
> duplicated the strings.
> And since the code im depcmp was similar, I did the same there, to keep
> things consistent.
> And I put a debug back because Aaron asked for it, and I also think it can
> be
> very handy sometimes, to debug quicker.

IMHO pacman debugging tends to be unusable.
The debug output of smoke001.py is now ~100MB(!!); before alpm_depcmp logging it
was "only" ~30MB. alpm_depcmp debugging added 1.5 million (!) lines. So even the
compressed output is 5 MB for me (user cannot attach this easily with an e-mail
etc. etc.). And don't forget that alpm_depcmp is used everywhere, so this is not
an extreme example: compute_requiredby, depcheck etc.
I simply cannot understand how this can help us. The debug.log is totally
unreadable now (at least to me), you have to know the debug format and search
for the interesting part (by doing this you may miss something...).
Logging atomic functions is simply needless imho (the same for "checking target1
target2 conflict"-like messages); the caller function usually informs us about
the result in a debug message (foo satisfies dependency bar, pulling into the
target list; foo conflicts with installed package bar, bar selected for removal
Bye, ngaba

SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/

More information about the pacman-dev mailing list