I have portage tree not readable for not portage group members: drwxr-s--- root portage /var/portage Older portage linked "files" and 3.0.24 copies it, but not preserving permissions/ownership it makes it unreadable in environments like mine.
Not sure I understand. This is by design with the changes in bug 814857, but I don't see how this matters right now: Portage should be able to read it during the build (and as root when required). What's actually breaking?
> Portage should be able to read it during the build (and as root when > required). What's actually breaking? Group ownership: # ll -d /var/portage/media-gfx/feh/files/ /var/tmp/portage/media-gfx/feh-3.7.2/files/ drwxr-s--- 2 root portage 4096 2019-09-11 /var/portage/media-gfx/feh/files/ drwxr-s--- 2 root root 4096 2019-09-11 /var/tmp/portage/media-gfx/feh-3.7.2/files/
The new behavior is exactly what we want to have. The change was added to not preserve the metadata on $FILESDIR, old code was symlinking it, now the code reflink or copy it intentionally dropping the metadata. If we were to add code to keep the groups then we have the old problem back. In this case I highly recommend you to make the tree world readable.
(In reply to Piotr Karbowski from comment #3) > If we were to add code to keep the groups then we have the old problem back. And what was that old problem? I had no problems until .24...
(In reply to Jan Psota from comment #2) > > Portage should be able to read it during the build (and as root when > > required). What's actually breaking? > > Group ownership: > # ll -d /var/portage/media-gfx/feh/files/ > /var/tmp/portage/media-gfx/feh-3.7.2/files/ > drwxr-s--- 2 root portage 4096 2019-09-11 /var/portage/media-gfx/feh/files/ > drwxr-s--- 2 root root 4096 2019-09-11 > /var/tmp/portage/media-gfx/feh-3.7.2/files/ There's a warning about this behavior near the top of the shutil documentation here: https://docs.python.org/3/library/shutil.html Warning Even the higher-level file copying functions (shutil.copy(), shutil.copy2()) cannot copy all file metadata. We can solve this by adding a call to apply_recursive_permissions like we have in the _post_phase_userpriv_perms function: > apply_recursive_permissions( > path, > uid=portage_uid, > gid=portage_gid, > dirmode=0o700, > dirmask=0, > filemode=0o600, > filemask=0, > )
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=6b2f67eddf66eb685cccfad3bec23147f318f420 commit 6b2f67eddf66eb685cccfad3bec23147f318f420 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2021-09-28 00:17:05 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2021-09-28 07:19:47 +0000 prepare_build_dirs: apply permissions to filesdir Bug: https://bugs.gentoo.org/815196 Reviewed-by: Michał Górny <mgorny@gentoo.org> Reviewed-by: Sam James <sam@gentoo.org> Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/portage/package/ebuild/prepare_build_dirs.py | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
(In reply to Jan Psota from comment #4) > (In reply to Piotr Karbowski from comment #3) > > If we were to add code to keep the groups then we have the old problem back. > And what was that old problem? I had no problems until .24... https://bugs.gentoo.org/show_bug.cgi?id=814857
I'll make another release now.
3.0.26 fixes this :-)
