On Sat, May 15, 2010 at 5:41 PM, Jonathan Conder <j@skurvy.no-ip.org> wrote:
Fixes FS#18770, and hopefully an occasional deadlock in my frontend as well. This introduces a new EVENT: PM_TRANS_EVT_SCRIPTLET_ERROR, and moves all scriptlet-related callbacks into the parent process.
I modelled my work on the GLib function g_spawn_sync, but I am quite unfamiliar with POSIX so there could be some issues with the implementation. However, all the tests I have performed so far (against v3.3.3) seemed to work fine (even the kernel installed and gave me the right warnings). This patch might also make it easier to configure the shell used for install scriptlets. I'm not 100% happy with the code structure at the moment, so any suggestions would be welcome.
Signed-off-by: Jonathan Conder <j@skurvy.no-ip.org>
Uhm I wonder how I managed to assign that bug to myself, whether it was on purpose or by mistake. I doubt I looked at it more than 5 seconds, since I couldn't remember that (fairly recent) bug at all . I had a much simpler patch lying around to just switch back from popen to execl, but since it just added complexity with no gain, I just let it die. I just attach it for reference, but its not important. Reading the bug again, I agree something must be done, but I am completely undecided which path to take. The easy way sounds attractive. So we should discuss a bit about how important that is : "stdout and stderr would be indistinguishable to the frontend". 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 ? 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. 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 ?