Doing this as a non-priv user: ebuild /usr/portage/x11-base/xorg-server/xorg-server-1.3.0.0-r5.ebuild unpack gets me this: * MesaLib-6.5.2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * xorg-server-1.3.0.0.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking xorg-server-1.3.0.0.tar.bz2 ;-) ... [ ok ] * checking MesaLib-6.5.2.tar.bz2 ;-) ... [ ok ] >>> cfg-update-1.8.2-r1: You need root privileges for this mode... * Forcing on xorg-x11 for new enough glxtokens.h... Switching to xorg-x11 OpenGL interface...rm: cannot remove `//etc/env.d/03opengl': Permission denied !!! Error: Failed to remove //etc/env.d/03opengl /usr/portage/x11-base/xorg-server/xorg-server-1.3.0.0-r5.ebuild: line 294: 18771 Killed eselect opengl set --impl-headers ${OPENGL_DIR} >>> Unpacking source...
Not sure I follow you ... you're using portage to emerge packages as a nonroot user? If so, I can't say it's surprising that you aren't allowed to write to arbitrary locations of the filesystem during the pkg_* ebuild phases.
No, I am just trying to unpack xorg-server using ebuild and it tries to remove a file in /etc. That is not what I expected. Surely I should be able to unpack and compile pkgs without it trying to remove/modify stuff in /etc?
Not really, no. The pkg_setup() phase runs first, and its a dependency of everything afterwards -- src_unpack(), src_compile(), etc. All pkg_* phases are allowed to touch the live filesystem as required. In this case, it has to set up eselect-opengl correctly to ensure that xorg-server actually compiles. One thing you could try is just running the setup step as root, like this: sudo ebuild foo.ebuild setup ebuild foo.ebuild unpack <stuff> ebuild foo.ebuild compile
hmm, this was news to me. I figured it was safe to test stuff using plain ebuild unpack/compile. Now you are telling me that this can break my system as these can mess with my root FS and even delete stuff. What is the safe way to unpack/compile ebuilds? Suppose emerge <a pkg> fails during compile, isn't there a chance you end up with a broken system as the pkg may have shuffled around stuff in /etc(or any other directory)?
(In reply to comment #4) > hmm, this was news to me. I figured it was safe to test stuff using > plain ebuild unpack/compile. Now you are telling me that > this can break my system as these can mess with my root FS and > even delete stuff. What is the safe way to unpack/compile > ebuilds? > > Suppose emerge <a pkg> fails during compile, isn't there a chance > you end up with a broken system as the pkg may have shuffled around stuff > in /etc(or any other directory)? Yes, you're absolutely right, there is a chance. Portage (wrongly) assumes success and makes no attempt to track filesystem changes during pkg_* phases for later reversion upon failure. Most changes involving file deletion and such (of which there are still very few) happen during pkg_preinst and pkg_postinst, which both happen after a successful compilation, because they're needed for installation rather than for compilation. That's why in general I don't get too concerned. If you want a guarantee, you could either implement the above Portage enhancement or do everything in a chroot.
ouch, I am not in a position to fix this in portage. Perhaps you can reassign this bug to the portage herd?
