Currently, default umask (022) is applied and it makes directories in svn-src writable by owner (which is portage). /usr/portage/distfiles permissions already allow for files to be written/deleted by portage group, that does not apply to subdirectories however - specifically source files stored by subversion_src_unpack and other scms. I'd propose to call umask g+w somewhere in subversion.eclass:subversion_src_unpack (with optional, but not really needed - chmod)
Created attachment 198089 [details, diff] Added ESVN_UMASK with umask invocation (no chmod) Proposed patch, with umask moved to separate eclass variable. Also patch removes two redundant parameter substitutions.
Created attachment 198091 [details, diff] fixed typo in die message
On the second thought, maybe giving too much freedom is not the best approach (being able to specify umask that will take away read permissions for portage itself...) So maybe just fix it to g+w? I'd need it anyway (along with existing ESVN_OFFLINE=1) to implement developer mode in kde4 eclass - being able to develop/patch/commit (being in portage group) directly to ESVN_STORE_DIR and utilize portage sandboxed installation and file collision prevention. If you know better (than umask) ways to achieve this, please let me know.
CC-ing other folks, maybe they will have some ideas.
Being able to test ebuilds as normal user is a big plus, and it's a pain if you always have to remove the subversion workdir as root first. So: bump!!!
Actually there's workaround I have in practice right now: - chown ${user}:${user} -R /usr/portage/distfiles/${scm}-src/* - put E${SCM}_OFFLINE=1 in make.conf This makes portage effectively unable to screw permissions there and make ${user} able to develop/patch source in distfiles directly. With additional scripts I can update all svn distfiles in one shot (which in kde case is preferred way).
Created attachment 220617 [details] SVN update script
As nobody really wants to do anything here, we can likely resolve this bug.
