Re: [PATCH] package_ipk: apply umask to control and conffiles

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2012-03-23 at 21:17 +0100, Andreas Oberritter wrote:
> On 12.03.2012 16:53, Richard Purdie wrote:
> > On Mon, 2012-03-12 at 10:29 -0500, Mark Hatle wrote:
> >> On 3/9/12 8:15 PM, Andreas Oberritter wrote:
> >>> * Explicitly set umask to 022. Otherwise the build system's
> >>>    umask leaks into the image.
> >>
> >> I'm surprised that do_package_ipk[umask] didn't work.  Perhaps its the way it's 
> >> being invoked that is the issue.  (If bitbake doesn't run it, but something else 
> >> does.. then the umask setting doesn't get used.)
> >>
> >> As for the change of the umask, the changes appear to be specific to the ipk 
> >> case.  Is this the desired behavior, or could deb and rpm suffer from similar 
> >> issues?  (I'm not familiar enough with opkg to know how it handles umask 
> >> settings during package install/rootfs construction..)
> >>
> >> I believe that RPM sets a default umask when it goes through it's package 
> >> installs/rootfs generation.  But does DEB?
> > 
> > I'm also a bit worried about this patch. I'd like to understand why a
> > task level umask doesn't work. That shouldn't even make any difference
> > since the permissions/owners/users from install should be getting
> > used...
>
> can you please give some advise on how to continue with this issue?

I understand half the problem now, the files with the issues are ones
created during the package_ipk task. That addresses one of my big
concerns.

The second thing I'd like to understand is why a task level umask
doesn't resolve this. Looking at what you tried, this might be as simple
as a typo:

do_package_ipk[umask] = "022"

when you really want:

do_package_write_ipk[umask] = "022"

If that works, lets set this for deb and rpm too so we're consistent and
I'll merge that patch :)

Cheers,

Richard