portage.py(line 6581 (current cvs)) If a user has a dir: drwxr-xr-x 2 root root 4096 Jul 28 10:02 /var/spool/wwwoffle/prevtime4 and an ebuild creates a dir: drwxr-xr-x 2 wwwoffle wwwoffle 4096 Jul 28 10:02 /var/tmp/portage/wwwoffle-2.8b/image/var/spool/wwwoffle/prevtime4 The merging of the ebuild fails to change the ownership, group and permissions of the destination directory. wwwoffle-2.8b works around this with a evil pkg_postinst.
I don't think this is something portage can legitimately do. Portage shouldn't modify your directory permissions.
More food for reconsideration: A version bumped ebuild will not be able to change the permissions on a directory even if the directory was created by a previous ebuild with different ownership/permissions? This introduces an inconsistency with the way portage handles directories different from files. If an ebuild creates a file, and the file exists in the ${ROOT} directory, it will be overwriten regardless of its permissions/ownership. How is a directory different? So to legitimately update the directory you would need to emerge -C the previous version and reemerge the update to get the correct permissions directories? If a security fix requires a permission/ownership change on a directory, is a "emerge security" going to be able to fix it (without using pkg_postinst?
the permissions shouldnt get changed by an incoming ebuild ... the problem is that, how is portage to know which permissions are the correct set ? some users like to tweak permissions on their dirs; they'd get pissed if portage kept turning around and resetting them on them ... so yes, the only real way to work around bum initial permissions is to have pkg_postinst do it up for you :/
