[pacman-dev] Pacman output issues

[Xavier]

On Mon, Oct 08, 2007 at 02:10:03PM -0500, Dan McGee wrote:
> A few questions to pose to the list before I make changes that need to
> be made since I busted some things up with the last few updates of
> pacman output trying to make it simpler.
> 
> 1. What information should go to stdout, and what information should
> go to stderr? I really should look at how it is done in the current
> 3.0 branch so I can get it right going forward in 3.1, but I want to
> make sure that what was done in 3.0 is right according to the list. I
> would think something like this:
> * non-essential info (progress meters and the like): stdout
> * list of packages to be upgraded, Y/n questions: this probably should
> go to stdout, but has gone to stderr in the past so that redirection
> of stdout works and users still see questions, and pacman doesn't seem
> to hang without reason. Thoughts?
> * "package is newer than...": stdout
> * errors/warnings: stderr
> 

That looks fine.
Redirecting the questions to stderr is a helpful hack indeed.

> 2. I introduced the pm_printf family of functions a while back but
> didn't switch much of the pacman output over to it. It mainly deals
> with not having to duplicate the use of "warning:" and "error:", etc
> in the code. Any reason not to use this as often as possible in the
> pacman code? I plan on doing this; I just want to first make sure I'm
> not making a stupid mistake. Obviously not everything will get
> switched (usage and help come to mind as being plain printf
> candidates), but I think just about everything else should go. My only
> thought holding me back is the fact that the error level codes are in
> libalpm and not the frontend, which may be a non-issue.
> 

Wasn't the ultimate goal to remove all logging from the backend?
Maybe starting to doing this in the frontend is a tiny step in that
direction :)
I am not sure though, I clearly don't know enough about this whole logging
stuff.

> 3. I broke the newline stuff. If a progress bar is going and some
> output needs to be placed on the screen, it doesn't end up on the next
> line. I'd really like a clean way to fix this- the old global variable
> way seemed very weird to me, or at least it was too complex. I have
> one idea in my head, but haven't sat down and tried it yet.
> 

You mean the following, right? :

42 static int neednl = 0; /* for cleaner message output */
43 static int needpad = 0; /* pad blanks to terminal width */

I think I suggested a while ago to somehow make libalpm remember all
the warning/error during extraction, for displaying them after the progress bar.
But this might be even more complex than the padding stuff from 3.0.