| Summary: | sys-apps/portage: enable userpriv and usersandbox by default in FEATURES | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Zac Medico <zmedico> |
| Component: | Core - Configuration | Assignee: | 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 | ||
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=769b5e5c70eb188b133e294cc47973a6c443fb1b This is fixed in 2.1.13 and 2.2.0_alpha189. *** Bug 484362 has been marked as a duplicate of this bug. *** *** Bug 484644 has been marked as a duplicate of this bug. *** *** Bug 484928 has been marked as a duplicate of this bug. *** *** Bug 485054 has been marked as a duplicate of this bug. *** 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. =). |
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