Current sys-apps/baselayouts does not create {,/usr}/{bin,sbin}. Profile 23.0 expects /bin to be a symlink, or die. Reproducible: Always Steps to Reproduce: 1. ROOT=/wherever/ PORTAGE_CONFIGROOT=/wherever/ emerge sys-apps/baselayout @system 2. chroot to /wherever/ and try to merge @world (that includes virtual/editor) 3. Don't know how other packages could be merged, but virtual/editor bails out when sourcing profile 23.0 bashrc Actual Results: emerge fails Expected Results: emerge succeeds Something like the following should do the trick mkdir -p "${EROOT}/usr/bin" "${EROOT}/usr/sbin" if use split-usr; then mkdir -p "${EROOT}/bin" "${EROOT}/sbin" else ln -s ../bin "${EROOT}/bin" ln -s ../sbin "${EROOT}/sbin" fi
(In reply to Étienne Buira from comment #0) > ln -s ../bin "${EROOT}/bin" > ln -s ../sbin "${EROOT}/sbin" This obviously should read ln -s usr/bin "${EROOT}/bin" ln -s usr/sbin "${EROOT}/sbin"
When setting up a fresh ROOT, you should install sys-apps/baselayout with the "build" USE flag set. This will cause the directories to be created via pkg_postinst. For example: USE=build emerge -v1O --root=/whereever sys-apps/baselayout Creating the directories in src_install would require the use of the keepdir function, and would just end up creating a pointless .keep file.
(In reply to Mike Gilbert from comment #2) > This will cause the directories to be created via pkg_postinst. This actually happens in pkg_preinst, my mistake.
(In reply to Mike Gilbert from comment #2) > When setting up a fresh ROOT, you should install sys-apps/baselayout with > the "build" USE flag set. One annoyance with doing that is then your first `emerge -uDU @world` is going to want to remerge sys-apps/baselayout with USE="-build". Seems as though one-off functionality like this ought to be invoked via pkg_config() rather than toggled by a USE flag, except that's not possible since pkg_config() requires that the package is already installed before it can be run. It might be nice if we had a pkg_prepare() phase function akin to src_prepare() but to prepare the target ROOT outside of the normal build cycle. Or maybe one-off functionality in pkg_preinst() simply ought to be controlled by an environment variable rather than by a USE flag.
(In reply to Matt Whitlock from comment #4) > One annoyance with doing that is then your first `emerge -uDU @world` is > going to want to remerge sys-apps/baselayout with USE="-build". baselayout is a trivially small package, so rebuilding it seems like a non-issue to me. That said, we could potentially adjust baselayout so that the steps performed by USE=build can be instead be executed based on the current contents of ${ROOT}, or even unconditionally.
(In reply to Mike Gilbert from comment #5) > (In reply to Matt Whitlock from comment #4) > > One annoyance with doing that is then your first `emerge -uDU @world` is > > going to want to remerge sys-apps/baselayout with USE="-build". > > baselayout is a trivially small package, so rebuilding it seems like a > non-issue to me. > > That said, we could potentially adjust baselayout so that the steps > performed by USE=build can be instead be executed based on the current > contents of ${ROOT}, or even unconditionally. It still can scare to rebuild a 'base' package. However, i vote for build use-flag removal, as it is a weird one (but thank you Mike for the trick). Executing depending on what is found seems the most sensible way (then, removing rm -fr /bin /sbin /usr/sbin [or trying a simple unlink] from layout-usrmerge target) OT: if someone is more in mood to add a useflag, a couple could be of use #916244
(In reply to Mike Gilbert from comment #5) > baselayout is a trivially small package, so rebuilding it seems like a > non-issue to me. Right, I agree in the case of baselayout, but my comments apply more generally to the several packages in the tree that have IUSE="build". It just seems like "there ought to be a better way."
