You cannot call emege in any ebuild or eclass. It is not safe as locking is not used everywhere and there are races in certain areas still.
thanks for reporting
> You cannot call emege in any ebuild or eclass. It is not safe as locking is > not used everywhere and there are races in certain areas still. not only that, but emerge also utilizes environment pollution to pass information, and the sandbox gets very very pissed
(In reply to comment #2) > not only that, but emerge also utilizes environment pollution to pass > information, and the sandbox gets very very pissed Do you have an example demonstrating how this breaks the sandbox? I'm not aware of anyone ever having a problem installing a web-based app because of the interaction between the environment pollution and the sandbox. Best regards, Stu
(In reply to comment #0) > You cannot call emege in any ebuild or eclass. It is not safe as locking is > not used everywhere and there are races in certain areas still. I believe we've been able to get away with this so far because webapps are at the bottom of the resolver tree, so to speak. Can you help me out by providing an example of where a missing lock or an existing race condition causes a problem with the way we're doing this? Do you have any suggestions on how we can switch away from calling emerge? Best regards, Stu
I have a suggestion that might solve this. We can introduce a new tool called webapp-cleaner. Instead of calling emerge -C from the eclass, we'll call 'webapp-cleaner --check-if-clean-required' instead. This mode will output a message if the user has web-based applications that need removing, and will prompt the user to run 'webapp-cleaner --clean ${PN}' for themselves. webapp-cleaner --clean will remove all installed web-based apps that have *not* been installed using webapp-config, by building up a call to emerge -C. This solution moves the emerge -C call out from the eclass into a tool that the user runs outside Portage. I believe that would satisfy all parties? Best regards, Stu
I think you can safely unmerge files without the need of using portage at all. It would take a little effort. But not so much. I've been over this with the portage team before about calling emerge from within an ebuild. You are the first guy to take the stance of saying it's a QA problem. While it's not ideal it can be done correctly by exporting the right variables.
(In reply to comment #5) > This solution moves the emerge -C call out from the eclass into a tool that the > user runs outside Portage. I believe that would satisfy all parties? Works for me.
*** Bug 127144 has been marked as a duplicate of this bug. ***
Created attachment 90810 [details] webapp-cleaner
Created attachment 90811 [details, diff] webapp.eclass_emerge.patch
I've attached webapp-cleaner and a corresponding patch to webapp.eclass. If this looks sane, I'd like to commit both soon.
webapp-cleaner is part of webapp-config-1.50.15
Ping? Any progress on this?
What I should have noted in comment #13 is that this is still causing problems as the eclass is still calling emerge...
We are currently waiting for a new version of webapp-config to be released (plus the 30 days required to get it stable). Best regards, Stu
The ~arch version of portage causes locking issues, since the parent emerge locks the vdb, and then in the eclass another emerge is executed, which then blocks waiting for the parent. This is a deadlock condition. This bug blocks the stabling of that version of portage and breaks webapps for ~arch users. Adding dev-portage to the CC Webapp team, how is your replacement coming along?
I restarted webapp-config development now and will try to fix this asap.
(In reply to comment #16) > The ~arch version of portage causes locking issues, since the parent emerge > locks the vdb, and then in the eclass another emerge is executed, which then > blocks waiting for the parent. This is a deadlock condition. As a workaround this, the eclass can remove ${ROOT}/var/db/.pkg.portage_lockfile before calling emerge. Yes, it defeats the whole purpose of the lock, but it's probably a better alternative than the deadlock that users are currently exposed to.
What? That's a horrible idea. This thing needs fixed, not worked around. Are you seriously suggesting adding yet another hack to webapp.eclass???
(In reply to comment #19) > What? That's a horrible idea. This thing needs fixed, not worked around. Are > you seriously suggesting adding yet another hack to webapp.eclass??? The current behavior is broken, and removing the lock file won't really make it it any worse than it already is. I just want the webapp.eclass maintainers to know all possible options.
In cvs I've added an ewarn message so that users experiencing a deadlock won't have to search in order to find out what went wrong: * This action may result in a deadlock. Please refer to * http://bugs.gentoo.org/show_bug.cgi?id=124440 for more information.
done
