7554 2015-03-31 17:08:40 +0000 Ownership issue in package contents 2016-08-19 06:28:22 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 1.7 All Multiple RESOLVED FIXED Medium major 2.2 M3 1 mario liezhi.yang joshuagloe mark.hatle meta.mr.watcher meta.watcher otavio randy.macleod ross.burton seebs sgw --- Unknown (Hard to categorize) No (bug/feature does not impact docs) oldest_to_newest 49997 0 mario 2015-03-31 17:08:40 +0000 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. 49999 1 seebs 2015-03-31 18:12:43 +0000 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). 50000 2 otavio 2015-03-31 18:14:59 +0000 Mario has tested in Dizzy and I reproduced same issue in Fido. We didn't test it outside BitBake. 50001 3 mark.hatle 2015-03-31 18:23:20 +0000 (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.) 50002 4 seebs 2015-03-31 19:14:02 +0000 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. 50093 5 mario 2015-04-06 13:09:58 +0000 The mailing list thread with comments on this issue can be found here: http://lists.openembedded.org/pipermail/openembedded-core/2015-March/103146.html 50270 6 mark.hatle 2015-04-13 15:38:16 +0000 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. 50575 7 mark.hatle 2015-04-28 18:38:06 +0000 The plan is to refactor some of the code to make using the fs-perms.txt override easier. 65335 8 liezhi.yang 2016-08-19 06:28:22 +0000 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]