Bugzilla Bug 58611

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 :/