Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 477664 - sys-apps/portage: enable userpriv and usersandbox by default in FEATURES
Summary: sys-apps/portage: enable userpriv and usersandbox by default in FEATURES
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Configuration (show other bugs)
Hardware: All All
: Normal normal (vote)
Assignee: Portage team
Keywords: InVCS
: 484362 484644 484928 485054 (view as bug list)
Depends on:
Blocks: 472632
  Show dependency tree
Reported: 2013-07-21 18:21 UTC by Zac Medico
Modified: 2013-09-18 08:39 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
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 {} +
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) (RETIRED) 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. =).