wrong umask used for creating sstate-cache directories

[Phil Blundell <philb@gnu.org>]

We've been experiencing a problem for a while with the group write bit
going missing on directories which are created inside sstate-cache.
This afternoon I finally had some time to investigate the cause of the
problem.

What appears to be happening is that, due to the way that sstate hooks
in its prefuncs/postfuncs, sstate_package() ends up inheriting any umask
which was set on the that that it's wrapping.  In particular, for
reasons that I'm not entirely clear about, base.bbclass does:

    if not bb.data.inherits_class('native', d) and not bb.data.inherits_class('cross', d):
        d.setVarFlag('do_configure', 'umask', 022)
        d.setVarFlag('do_compile', 'umask', 022)
        d.appendVarFlag('do_install', 'depends', ' virtual/fakeroot-native:do_populate_sysroot')
        d.setVarFlag('do_install', 'fakeroot', 1)
        d.setVarFlag('do_install', 'umask', 022)
        d.appendVarFlag('do_package', 'depends', ' virtual/fakeroot-native:do_populate_sysroot')
        d.setVarFlag('do_package', 'fakeroot', 1)
        d.setVarFlag('do_package', 'umask', 022)
        d.setVarFlag('do_package_setscene', 'fakeroot', 1)

and staging.bbclass does:

	do_populate_sysroot[umask] = "022"

sstate_create_package() takes care to explicitly change the mode on the
newly-created archive file to 0664, but there is no equivalent handling
for the directories created by the mkdirhier() calls in sstate_package()
and those end up getting their mode determined by the umask in effect.

In order to work around this problem I've applied this patch locally:

--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -507,7 +507,11 @@ python sstate_task_postfunc () {
     sstate_install(shared_state, d)
     for intercept in shared_state['interceptfuncs']:
         bb.build.exec_func(intercept, d)
+    omask = os.umask(002)
+    if omask != 002:
+       bb.note("Using umask 002 (not %03o) for sstate packaging" % omask)
     sstate_package(shared_state, d)
+    os.umask(omask)

but this is clearly not ideal for general consumption either since some
people might actually want umask 022 for those directories.  The ideal
thing would be if bitbake could either restore the original umask before
running the postfuncs, or at least allow code in the postfunc to find
out what the original umask was so that it could restore it for itself.

Any better suggestions?

p.