[pacman-dev] [PATCH] redirect scriptlet stderr through alpm
j at skurvy.no-ip.org
Sun May 16 16:39:44 EDT 2010
On Sun, 2010-05-16 at 14:02 +0200, Xavier Chantry wrote:
> It sounds fine to distinguish both and might be the cleanest solution,
> but I have two questions :
> 1) Do applications (in particular the ones used in scriptlets) have a
> consistent usage of stdout and stderr ?
> 2) How would frontend display / handle the stdout and stderr output ?
1) I've never seen a script that uses stderr explicitly, but commands
that get called use it when something goes wrong.
2) My frontend doesn't make a distinction, although I am limited by the
API of PackageKit. I can't speak for other frontends though.
> If all frontend just end up doing like pacman, displaying/mixing both
> output together, then I wonder if we need to bother with all this.
Maybe you're right, and it would probably make sense if someone wanted
to write a log of pacman output, they could use > instead of &>.
However, Allan seemed to imply that this wasn't the best solution,
although I think now I might have misread that. See
> But if you also have other justifications, that could be even more convincing.
> Can you elaborate on the occasional deadlock you get and how it is fixed ?
I haven't been able to reproduce it since it happened last, but in my
experience that usually indicates a race condition of some sort.
However, I do know it occurred somewhere inside my
PM_TRANS_EVT_SCRIPTLET_INFO callback, which makes a D-Bus call to pass
the message to the GUI. I suspect that the problem is something to do
with that, because dbus-glib is not thread-safe, let alone fork-safe. In
any case I think it is more reliable to call all callbacks (including
logging) in the parent process.
More information about the pacman-dev