I guess pkg_setup() is not the best place for rm. Infact I modified the actually function in: # remove system module since it depends on hal and we don't # have hal in portage anymore ls -la "${S}"/modules/ rm -rf "${S}"/modules/system || die and the result is: ls: cannot access /var/tmp/portage/app-laptop/prey-0.5.4/work/prey/modules/: No such file or directory Now I added another ls in src_prepare, just to see what happens and: total 44 drwxr-xr-x 11 portage portage 4096 Dec 26 2011 . drwxr-xr-x 7 portage portage 4096 Dec 26 2011 .. drwxr-xr-x 5 portage portage 4096 Dec 26 2011 alarm drwxr-xr-x 6 portage portage 4096 Dec 26 2011 alert drwxr-xr-x 4 portage portage 4096 Dec 26 2011 geo drwxr-xr-x 5 portage portage 4096 Dec 26 2011 lock drwxr-xr-x 5 portage portage 4096 Dec 26 2011 network drwxr-xr-x 4 portage portage 4096 Dec 26 2011 secure drwxr-xr-x 5 portage portage 4096 Dec 26 2011 session drwxr-xr-x 5 portage portage 4096 Dec 26 2011 system drwxr-xr-x 5 portage portage 4096 Dec 26 2011 webcam system is still here.
+ 05 Oct 2012; Agostino Sarubbo <ago@gentoo.org> prey-0.5.4.ebuild: + Move rm to src_prepare(), wrt to bug #437294 +
Why did you open a bug assigned to me if you are going to fix it yourself? I never gave my ACK so you should have gave me at least a day to see this bug. After all I am the maintainer ;)
(In reply to comment #2) > Why did you open a bug assigned to me if you are going to fix it yourself? I > never gave my ACK so you should have gave me at least a day to see this bug. > After all I am the maintainer ;) The bug is trivial, I open this to track the issue.
Still, metadata.xml is there for a reason
(In reply to comment #4) > Still, metadata.xml is there for a reason You completely right, but sorry not for this case. I always ask before touchi anythin, but I don't think I need permission to move rm in the _right_ function because actually does _not_ work. If you don't agree with my mind, next time I will file a bug without touching.
