Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 477664

Summary: sys-apps/portage: enable userpriv and usersandbox by default in FEATURES
Product: Portage Development Reporter: Zac Medico <zmedico>
Component: Core - ConfigurationAssignee: Portage team <dev-portage>
Status: RESOLVED FIXED    
Severity: normal CC: gentoo, kentnl, pacho, patrick, phajdan.jr, Tanktalus
Priority: Normal Keywords: InVCS
Version: 2.1   
Hardware: All   
OS: All   
URL: http://thread.gmane.org/gmane.linux.gentoo.devel/77362
See Also: https://bugs.gentoo.org/show_bug.cgi?id=477682
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 472632    

Description Zac Medico gentoo-dev 2013-07-21 18:21:26 UTC
The portage ebuild's pkg_postinst will have to adjust live sources permission in $DISTDIR, since src_unpack will run as the "portage" user instead of root. Something like this should do the trick:

  if $USEPRIV_UPGRADE ; then
    find "${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}" -maxdepth 1 -type d -uid 0 \
      -exec chown -R portage:portage {} +
  fi
Comment 2 Zac Medico gentoo-dev 2013-07-26 07:11:03 UTC
This is fixed in 2.1.13 and 2.2.0_alpha189.
Comment 3 Zac Medico gentoo-dev 2013-09-09 17:56:31 UTC
*** Bug 484362 has been marked as a duplicate of this bug. ***
Comment 4 Zac Medico gentoo-dev 2013-09-12 16:09:28 UTC
*** Bug 484644 has been marked as a duplicate of this bug. ***
Comment 5 Zac Medico gentoo-dev 2013-09-15 00:34:28 UTC
*** Bug 484928 has been marked as a duplicate of this bug. ***
Comment 6 Zac Medico gentoo-dev 2013-09-16 14:25:46 UTC
*** Bug 485054 has been marked as a duplicate of this bug. ***
Comment 7 Kent Fredric (IRC: kent\n) gentoo-dev 2013-09-18 08:39:52 UTC
re #485054 , I do understand why this happens, its just at the time, I was not expecting it.

If a file that exists in DISTFILES is not readable by portage, that failure should be recognized *LONG* before src_unpack 

Its all fine and dandy when portage downloads everything itself, but when you ask a user to fetch a file manually and move it into the directory, you're relying on their memory that they *need* to change the permissions to make portage happy.

Even when I saw the failure the first time, I thought it was something wrong in the *ebuild* and I spent a while tracking down the java ebuild source logic before I realized that it was actually just a PEBKAC

I'm not sure where the right place to fail is, ideally pkg_pretend , and if thats not a viable location, it should be somewhere inside the src_fetch/src_unpack layer so the user can be told what they did wrong, and that it *was* their fault and not the ebuild that made a mistake.

I know *portage* can tell if a file is downloaded or not ( on a fetch restricted package ), by the end of --ask , because the indicator changes, so it makes sense that the indicator check could also determine if the file is readable or not at the same time, and yield respective errors.

My apologies if this sounds like I'm tacking on a feature request to an existing bug, but I did open a bug for this scenario, ... but it was marked as a dupe of this bug, which is marked resolved.

I still made the mistake, and nothing told me I'd made the mistake till it was a lot later down the track, so this is still "an open bug" for me, because I'm likely to forget the same as I did this time at a future time, and I'll repeat the problem. =).