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 http://mailman.archlinux.org/pipermail/pacman-dev/2010-April/010618.html.
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. Jonathan