Build host intel i5 generating bin-pkgs for amd64 embedded (pcengines apu2c4) using this script (CHOST="x86_64-pc-linux-gnu"): #!/bin/bash export ROOT=/mnt/apu2 export PORTAGE_CONFIGROOT=$ROOT /usr/bin/emerge --root=$ROOT --root-deps --config-root=$ROOT "$@" cross emerge of www-servers/nginx-1.12.1: 1) created users/groups are created in /etc/passwd, /etc/group instead of ${ROOT}/etc/passwd, ${ROOT}/etc/group 2) portage build logs stored in /var/log/portage instead of ${PORTAGE_CONFIGROOT}/var/log/portage which mixes up genlop results Reproducible: Always Steps to Reproduce: 1. in build host environment not in a chroot where CHOST==CBUILD 2. export ROOT=/mnt/apu2; export PORTAGE_CONFIGROOT=$ROOT 3. emerge --root=$ROOT --root-deps --config-root=$ROOT nginx Actual Results: 1) Package installed in /mnt/apu2 as is binary package 2) user and group nginx added to build host's users/groups 3) portage build log placed in build host's /var/log/portage Expected Results: 1) Package installed in /mnt/apu2 as is binary package (as expected) 2) user and group ngix added to cross destination's ($ROOT) users/groups 3) build log placed in alternate portage config's ($PORTAGE_CONFIGROOT) var/log/portage useradd/mod and groupadd/mod have --root options may be useful Workarounds are: 2) manually copy the user/group from build host to chroot destination BUT this does require knowing that a package creates users/groups 3) temporarily set chroot's PORT_LOGDIR using host's absolute path for chroot's /var/log/portage
Created attachment 511692 [details] emerge --info using cross-emerge wrapper
(In reply to LW from comment #0) > Expected Results: > 1) Package installed in /mnt/apu2 as is binary package (as expected) > 2) user and group ngix added to cross destination's ($ROOT) users/groups The user/group issue is bug 53269. > 3) build log placed in alternate portage config's ($PORTAGE_CONFIGROOT) > var/log/portage Logs and configs are 2 different things, so it doesn't necessarily make sense to force give an implicit $PORTAGE_CONFIGROOT prefix to $PORT_LOGDIR. If that's where you want the logs to land, then you'll have to set PORT_LOGDIR accordingly. Forcing a new behavior on all users would not be nice, ans it would remove flexibility since there would be no straightforward way to put the logs outside of $PORTAGE_CONFIGROOT.
(In reply to Zac Medico from comment #2) > (In reply to LW from comment #0) > > Expected Results: > > 1) Package installed in /mnt/apu2 as is binary package (as expected) > > 2) user and group ngix added to cross destination's ($ROOT) users/groups > > The user/group issue is bug 53269. Sorry for the dupe, my bugzilla searches didn't turn up that bug or any of the others marked as dupes. > > Logs and configs are 2 different things, so it doesn't necessarily make > sense to force give an implicit $PORTAGE_CONFIGROOT prefix to $PORT_LOGDIR. > If that's where you want the logs to land, then you'll have to set > PORT_LOGDIR accordingly. > > Forcing a new behavior on all users would not be nice, ans it would remove > flexibility since there would be no straightforward way to put the logs > outside of $PORTAGE_CONFIGROOT. OK. This means though that emerge while chrooted and emerge with --config-root not chrooted have a (subtle?) difference. It can look like the log disappeared if one is used to finding them in the chroot when emerging from inside the chroot. Maybe --config-root's description needs to point out that logs from regular emerge and --config-root emerge can be mixed together, and that genlop's output on the build host would then be affected. A workaround is to use /var/log/portage/apu for $PORT_LOGDIR in the chroot, create that dir on the host and in the chroot and then bind mount the host's dir to the chroot dir. Not a killer, it just makes cross emerge a little bit more complicated. Has the idea of a $PORTAGE_CONFIGROOT_LOGDIR (defaulting to $PORT_LOGDIR) been considered before? I don't program in python otherwise I'd try help with prototyping. If the devs think it is not worth fixing relative to other issues, consider the log path issue resolved.
User part is indeed sorted by now fixed bug 541406.
