Created attachment 406252 [details, diff] have gcc_quick_unpack do the unpack even more quickly Since unpack() does "chmod -R $WORKDIR/*" on each invocation, gcc_quick_unpack() may slow down on various operating-/file-systems, depending on the number of tarballs to unpack. Instead, gcc_quick_unpack() better should invoke unpack() only once. Thanks!
i think you missed that not all tarballs are unpacked into $WORKDIR this should be mitigated in portage itself by using a `find -exec chmod` so it only operates on paths that need to be updated. it still would walk all the paths, but it would be faster than `chmod -R`.
Created attachment 406294 [details, diff] unpack(): do chmod when needed only (In reply to SpanKY from comment #1) Indeed, D Some timings collected on x86_64-cygwin (Windows Server 2012r2): >>> Unpacking gcc-4.9.3.tar.bz2 to ... >>> Unpacking gcc-4.9.3-patches-1.0.tar.bz2 ... >>> Unpacking gcc-4.9.3-uclibc-patches-1.0.tar.bz2 to ... >>> Unpacking gcc-4.9.3-piepatches-v0.6.2.tar.bz2 to ... >>> Unpacking gcc-4.4.3-specs-0.2.0.tar.bz2 to ... multiple unpack, chmod -R : ~6m 5s single unpack, chmod -R : ~3m 50s multiple unpack, find !-perm: ~3m 20s single unpack, find !-perm: ~3m 5s
Comment on attachment 406294 [details, diff] unpack(): do chmod when needed only looks nice. would be good to change to -exec chmod ... + too. find . -mindepth 1 '!' -type l '!' -perm /a+rX,u+w,g-w,o-w \ -exec chmod -f a+rX,u+w,g-w,o-w +
Created attachment 406306 [details, diff] unpack(): do chmod when needed only
Released in portage-2.2.21
let's re-open since the change has been reverted
As noted in bug 561368, comment #8, the find command fails as follows: $ find . -mindepth 1 '!' -type l '!' -perm /a+rX,u+w,g-w,o-w find: `./mod_auth_token': Permission denied Maybe we should have an internal helper script, written in python, to check permissions with os.lstat and call os.chmod when needed.
There's a patch in the following branch: https://github.com/zmedico/portage/tree/bug_554084 You can test it like this: echo '=sys-apps/portage-9999 **' >> /etc/portage/package.accept_keywords portage_LIVE_BRANCH=bug_554084 \ portage_LIVE_REPO=https://github.com/zmedico/portage.git \ emerge -1 =sys-apps/portage-9999 I've posted it for review here: https://archives.gentoo.org/gentoo-portage-dev/message/79c5e7cee2369123836d342ea78fed86
This is in the master branch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=b7baeeec3ab6d1e944a2d1f9ab5d4d6ccebd97e8
Fixed in 2.2.23, including this related patch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=597987aac1677e132b80ed2404697acf0188af7a
