I'm observing an issue with directory ownership in package contents. Not sure if I'm overlooking something really basic or if I hit a bug. Here's a minimal recipe to illustrate the problem: $ cat foo.bb LICENSE = "CLOSED" inherit useradd USERADD_PACKAGES = "${PN}" USERADD_PARAM_${PN} = "foo" do_install() { install -d -m 755 ${D}${libdir}/foo touch ${D}${libdir}/foo/bar chown -R foo:foo ${D}${libdir}/foo } Here's the package content: $ dpkg -c foo_1.0-r0.0_cortexa9hf-vfp-neon.ipk drwxrwxrwx root/root 0 2015-03-27 13:37 ./ drwxr-xr-x root/root 0 2015-03-27 13:37 ./usr/ drwxr-xr-x root/root 0 2015-03-27 13:37 ./usr/lib/ drwxr-xr-x root/root 0 2015-03-27 13:37 ./usr/lib/foo/ -rw-r--r-- foo/foo 0 2015-03-27 13:37 ./usr/lib/foo/bar Note that, although I run "chown -R foo:foo ${D}${libdir}/foo" in the recipe, ./usr/lib/foo/ in the package is owned by root. However, its content has the right ownership. I also generated and checked the rpm package and observed the same issue.
Hmm. Can you reproduce this outside of bitbake? I did a simple test with install/touch/chown with just pseudo, and got the behavior I expected (which for this would have been that both foo and foo/bar would be foo:foo).
Mario has tested in Dizzy and I reproduced same issue in Fido. We didn't test it outside BitBake.
(copied from email reply) I'd suggest you look at meta/classes/package.bbclass "fixup_perms" function. The ${D}${libdir} (and above) are "corrected" to be 'root:root' by this function. I don't know why 'foo' would be, but if it's a standard defined variable -- or if 'directory walking' is enabled it could end up doing this as well. The control file for this is in meta/files/fs-perms.txt (unless otherwise defined by a distribution or other configuration file.) Format of the file is: # The format of this file # #<path> <mode> <uid> <gid> <walk> <fmode> <fuid> <fgid> # # or # #<path> link <target> # # <path>: directory path # <mode>: mode for directory # <uid>: uid for directory # <gid>: gid for directory # <walk>: recursively walk the directory? true or false # <fmode>: if walking, new mode for files # <fuid>: if walking, new uid for files # <fgid>: if walking, new gid for files # <target>: turn the directory into a symlink point to target The default is: base_prefix 0755 root root false - - - prefix 0755 root root false - - - exec_prefix 0755 root root false - - - base_bindir 0755 root root false - - - base_sbindir 0755 root root false - - - base_libdir 0755 root root false - - - datadir 0755 root root false - - - sysconfdir 0755 root root false - - - servicedir 0755 root root false - - - sharedstatedir 0755 root root false - - - localstatedir 0755 root root false - - - infodir 0755 root root false - - - mandir 0755 root root false - - - docdir 0755 root root false - - - bindir 0755 root root false - - - sbindir 0755 root root false - - - libexecdir 0755 root root false - - - libdir 0755 root root false - - - includedir 0755 root root false - - - oldincludedir 0755 root root false - - - The easiest way to debug all of this is to edit meta/classes/package.bbclass, find the following lines: # Debug -- list out in-memory table #for dir in fs_perms_table: # bb.note("Fixup Perms: %s: %s" % (dir, str(fs_perms_table[dir]))) remove the '#' from the 'for' and following lines, then inspect the table from the build logs. Similarly, you can trace the actual fixups, by searching for def fix_perms(path, mode, uid, gid, dir):, and removing the comment from the two bb.note entries. This should give you an idea if this code is replacing your value with it's own. (I give this a VERY low probability that it's a bug in pseudo.)
In general, given the complexity of bitbake and oe-core, I like to find reproducers just using pseudo directly, since that way I can confirm that it's actually pseudo doing something wrong, not pseudo correctly doing whatever it was told to do.
The mailing list thread with comments on this issue can be found here: http://lists.openembedded.org/pipermail/openembedded-core/2015-March/103146.html
The mailing list thread ended with a manual fs-perms.txt for the recipe worked around the issue. I would lower the priority of this issue.. And we should work to improve the implementation in a future version of the Yocto Project. See the mailing list discussion for general suggestions for refactoring some of the code.
The plan is to refactor some of the code to make using the fs-perms.txt override easier.
I can't reproduce the problem with the following cases any more on master branch, so close it, please feel free to reopen it if you can reproduce it. diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb b/meta/recipes-core/base-files/base-files_3.0.14.bb --- a/meta/recipes-core/base-files/base-files_3.0.14.bb +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb @@ -155,6 +155,13 @@ do_install_basefilesissue () { fi } +do_install_append() { + mkdir -p ${D}/usr/lib/hello/world/foodir + touch ${D}/usr/lib/hello/world/foodir/foofile + chown mail:mail -R ${D}/usr/lib/hello + +} + do_install_append_linuxstdbase() { for d in ${dirs755-lsb}; do install -m 0755 -d ${D}$d $ bitbake base-files $ rpm -qpl -vvv tmp/deploy/rpm/qemux86/base-files-3.0.14-r89.qemux86.rpm [snip] drwxr-xr-x 2 root root 0 Aug 18 23:19 /usr/lib drwxr-xr-x 2 mail mail 0 Aug 18 23:19 /usr/lib/hello drwxr-xr-x 2 mail mail 0 Aug 18 23:19 /usr/lib/hello/world drwxr-xr-x 2 mail mail 0 Aug 18 23:19 /usr/lib/hello/world/foodir -rw-r--r-- 1 mail mail 0 Aug 18 23:19 /usr/lib/hello/world/foodir/foofile [snip]