7040 2014-12-08 13:32:45 +0000 Support for /usr merge (à la systemd and Fedora) 2017-07-18 08:58:48 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.7 x86 Multiple RESOLVED FIXED https://bugzilla.yoctoproject.org/show_bug.cgi?id=5143 Medium+ enhancement 2.4 M2 1 peter.kjellerstedt amarnath.valluri amarnath.valluri andrew f.schuettler jku joshuagloe matti-pekka.sivosuo meta.mr.watcher meta.watcher mikko.ylinen Qi.Chen randy.macleod richard.purdie ross.burton --- --- Don't know oldest_to_newest 47422 0 peter.kjellerstedt 2014-12-08 13:32:45 +0000 We would like to be able to configure our embedded system with a merged /usr à la Fedora. Preferably through a simple DISTRO_FEATURE. Typically this would involve having /bin, /sbin and /lib* be symbolic links to their /usr counterparts. From a discussion on the oe-core mailing list I gathered that files/fs-perms.txt would need to be modified, as well as changing ${base_bindir}, ${base_sbindir} and ${base_libdir}. According to Mark Hattle it should be pretty straightforward to redirect the /usr directories to their / counterparts. However, according to Chen Qi, the opposite is more troublesome and will require changes. For reference: http://0pointer.de/blog/projects/the-usr-merge 47496 1 richard.purdie 2014-12-11 15:43:42 +0000 In the past OE has supported a model where the prefix was changed and the /usr directory was removed entirely (or could be a sumlink). This proposal seems to be different in that /usr is retained with symlinks to the usr counterparts. This isn't something anyone I know is working on, hence the priority its being assigned. If someone is going to get it working, that would be fine, as long as the changes are not too invasive to the system. If it proves invasive, I'd much prefer the prefix approach since we know that isn't too invasive. 63415 2 joshuagloe 2016-06-28 16:46:40 +0000 *** Bug 9722 has been marked as a duplicate of this bug. *** 63416 3 joshuagloe 2016-06-28 16:49:03 +0000 A bunch of progress towards this has been made in master over recent releases and further supporting changes are being developed in my joshuagl/usrmerge branch on poky-contrib: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=joshuagl/usrmerge Building that tree with the usrmerge DISTRO_FEATURE enabled results in a failure to generate the rootfs with Smart and several warnings when using other package managers (opkg and dpkg). In both cases the root problem is the same, various of our scripts have a shebang of /bin/bash (or other utilities in /bin in some cases, i.e. sed) which is not present as we now install those binaries to /usr/bin We need to come up with a generic solution to this problem which doesn't involve manually patching all of the shell scripts a package might include… 69475 4 jku 2017-01-04 10:10:49 +0000 (In reply to comment #3) > Building that tree with the usrmerge DISTRO_FEATURE enabled results in a > failure to generate the rootfs with Smart and several warnings when using > other package managers (opkg and dpkg). > > In both cases the root problem is the same, various of our scripts have a > shebang of /bin/bash (or other utilities in /bin in some cases, i.e. sed) > which is not present as we now install those binaries to /usr/bin > > We need to come up with a generic solution to this problem which doesn't > involve manually patching all of the shell scripts a package might include… I've been testing this stuff a little. There are some minor issues I want to fix but the two major problems are: 1. build time dependencies to /bin or /lib. I think we want to create the symlinks in the sysroots (when "usrmerge" is in DISTRO_FEATURES): otherwise things will fail and we might not even notice. Currently e.g. gobject-introspection fails to build and many postinst scripts fail at rootfs generation because prelink-rtld looks for "/lib/ld-linux.so.2". This is not possible in a normal recipe (like base-files) because of how staging.bbclass currently works. 2. FILERDEPENDS on e.g. /bin/sh With rpm this means install fails as nothing RPROVIDES /bin/sh. Calling /bin/sh works because the symlink is there and /usr/bin/sh exists. I'm not 100% sure what the right fix would be... Considering this: * Make sure FILERDEPENDS is always tweaked to point to e.g. /usr/bin/sh * Add a QA check for not packaging things into /bin (etc) -- currently only kernel seems to break this in oe-core 73041 5 mikko.ylinen 2017-05-04 12:39:01 +0000 All patches were sent but some are still missing http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134354.html Can the remaining patches be prioritized for 2.4M1? 73051 6 ross.burton 2017-05-04 15:21:45 +0000 Mikko: can someone rebase the outstanding patches to master and publish the branch somewhere for constructive review? 73074 7 amarnath.valluri 2017-05-05 07:50:25 +0000 Ross, the rebased changes are on my repo on github: https://github.com/avalluri/openembedded-core/commits/usrmerge 73405 8 amarnath.valluri 2017-05-22 12:22:43 +0000 Ross, did you get chance to look at the patchset 74451 9 jku 2017-06-22 07:21:50 +0000 Amarnath, sorry for not being more active on this lately. I've assigned to you as an acknowledgement of reality... if you disagree: that's not a problem, just assign it back to me. If there's something I can do to help with the patches, I can try but currently I'm not up-to-date on them. 74452 10 jku 2017-06-22 07:25:40 +0000 (In reply to comment #9) > Amarnath, sorry for not being more active on this lately. I've assigned to > you as an acknowledgement of reality... if you disagree: that's not a > problem, just assign it back to me. Oh and the milestone needs to be changed if the patches are not in M1: I didn't want to decide on the milestone without being up to date on the state of patchset... 74453 11 amarnath.valluri 2017-06-22 07:34:25 +0000 Jussi, All the review comments are addressed, and still 7 patches needs to be accepted. The rebased changes are here: https://github.com/avalluri/openembedded-core/commits/usrmerge 74454 12 amarnath.valluri 2017-06-22 07:56:55 +0000 RP/Ross: Can you pleases suggest if we can take this for M1, i feel its bit unrealistic as we are nearing the milestone. 75097 13 amarnath.valluri 2017-07-18 08:58:48 +0000 All the needed patches landed in oe-core master.