First, I apologise for this being two bugs in one, but I think they're quite related. 1) When using PORTAGE_CONFIGROOT, sets are only being read from /etc/portage/sets/, not from ${PORTAGE_CONFIGROOT}/etc/portage/sets/ 2) When using PORTAGE_CONFIGROOT, variable PORTAGE_BINHOST seems to be handled in a weird way. My /etc/make.conf is set up _without_ any PORTAGE_BINHOST My /testroot/etc/make.conf is set up _with_ a specific PORTAGE_BINHOST The command: "PORTAGE_CONFIGROOT=/testroot ROOT=/testroot emerge --usepkg system" produces the following output: Calculating dependencies /!!! PORTAGE_BINHOST unset, but use is requested. Following that is a successful unmerge using the (nonexistant) BINHOST. To be clear, portage complains about not having a PORTAGE_BINHOST, yet it uses exactly that binhost to download all packages. Which is correct behaviour. If i set PORTAGE_BINHOST in original root (eg. /etc/make.conf) to "xxx", the same command as above immediately fails, saying something about invalid BINHOST. So my assumption is that portage checks the value of PORTAGE_BINHOST from the _wrong_ make.conf without respect to PORTAGE_CONFIGROOT, and then in turn uses the value from the _correct_ make.conf. I'll gladly supply more information. Reproducible: Always Steps to Reproduce:
(In reply to comment #0) > 1) When using PORTAGE_CONFIGROOT, sets are only being read from > /etc/portage/sets/, not from ${PORTAGE_CONFIGROOT}/etc/portage/sets/ This comes from /usr/share/portage/config/sets.conf: [usersets] class = portage.sets.files.StaticFileSet multiset = true directory = /etc/portage/sets We'll have to add some way to substitute PORTAGE_CONFIGROOT in there. Until then, you can override it in /testroot/etc/portage/sets.conf, like this: [usersets] directory = /testroot/etc/portage/sets > So my assumption is that portage checks the value of PORTAGE_BINHOST from the > _wrong_ make.conf without respect to PORTAGE_CONFIGROOT, and then in turn uses > the value from the _correct_ make.conf. Well, it checks both of them, since the default behavior is to satisfy build time dependencies (from the ebuild's DEPEND variable) by installing them to ROOT=/. However, in portage-2.2_rc30, there is a new --root-deps options which can (from bug 222895) which can be used to control this. Even if you use --root-deps, you will still receive the warning message. I'll fix it so that you won't get a warning as long as PORTAGE_BINHOST is defined for the target root.
(In reply to comment #1) > This comes from /usr/share/portage/config/sets.conf: > > [usersets] > class = portage.sets.files.StaticFileSet > multiset = true > directory = /etc/portage/sets > > We'll have to add some way to substitute PORTAGE_CONFIGROOT in there. Until > then, you can override it in /testroot/etc/portage/sets.conf, like this: > > [usersets] > directory = /testroot/etc/portage/sets That's just as a dirty hack as would simply be copying the /testroot/etc/portage/sets/* into /etc/portage/sets/. Nothing like the elegance of PORTAGE_CONFIGROOT Maybe you could make one of the set definitions "privileged" in a way that portage will automatically prefix it with PORTAGE_CONFIGROOT. Nothing wrong with that IMO, as long as you note it in a comment next to it. Hell, even simpler solution: take _ALL_ of the entries in this file, prefix them with PORTAGE_CONFIGROOT (if defined) and add to the head of the list. Or probably the best solution wrt. to generality, check for PORTAGE_CONFIGROOT first, then look up ${PORTAGE_CONFIGROOT}/usr/share/portage/config/sets.conf, and use that, all of the entries prefixed with ${PORTAGE_CONFIGROOT}/ > Even if you use --root-deps, you will still receive the warning message. I'll > fix it so that you won't get a warning as long as PORTAGE_BINHOST is defined > for the target root. That would be awesome. What i'm slightly worried by is, what would happen if both root and target BINHOSTS were valid? Would it use packages from both? In my case, I'm emerging a cross-compiled root (ie. binary incompatible) and I have different BINHOSTS for different platforms. Mixing them would be a disaster, and the /etc/make.conf BINHOSTS _must_not_ be used.
(In reply to comment #2) > Hell, even simpler solution: take _ALL_ of the entries in this file, prefix > them with PORTAGE_CONFIGROOT (if defined) and add to the head of the list. It's not that simple because each different set type can have any number of parameters that may or may not be file paths and if they are file paths then whether or not it make sense to join those paths with PORTAGE_CONFIGROOT would depend on the specific set and parameter (and may even vary for the same set and the same parameter). So, I think a substitution approach is the cleanest and most flexible. I'm not sure about the exact substitution syntax yet, but if it used shell syntax then it could look like this: [usersets] class = portage.sets.files.StaticFileSet multiset = true directory = ${PORTAGE_CONFIGROOT}/etc/portage/sets > That would be awesome. What i'm slightly worried by is, what would happen if > both root and target BINHOSTS were valid? Would it use packages from both? In > my case, I'm emerging a cross-compiled root (ie. binary incompatible) and I > have different BINHOSTS for different platforms. Mixing them would be a > disaster, and the /etc/make.conf BINHOSTS _must_not_ be used. It's not a problem because there is a separate configuration for each ROOT, and packages are never mixed between them (unless both ROOTs happen to have the same exact configuration).
(In reply to comment #3) > it used shell syntax then it could look like this: > > [usersets] > class = portage.sets.files.StaticFileSet > multiset = true > directory = ${PORTAGE_CONFIGROOT}/etc/portage/sets Sounds fair. Thanks!
Prefixing things with $(PORTAGE_CONFIGROOT) looks to be an excellent solution. I am concerned with the following... When I emerge --root=/mnt/xfs/tabby --config-root=/mnt/xfs/tabby --info, CONFIG_PROTECT="/etc ..." does that mean /etc or /mnt/xfs/tabby/etc? Portage 2.2_rc67 (default/linux/amd64/10.0/desktop, gcc-4.3.4, glibc-2.11.2-r3, 2.6.31-gentoo-r6 x86_64) ================================================================= System uname: Linux-2.6.31-gentoo-r6-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-gentoo-2.0.1 Timestamp of tree: Wed, 24 Nov 2010 20:45:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] ccache version 2.4 [disabled] app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11-r1 dev-lang/python: 2.4.6, 2.6.5-r3, 3.1.2-r4 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1-r1 sys-apps/openrc: 0.6.5 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.3.4, 4.4.4-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=k8 -O2 -pipe -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://gentoo.mirrors.tds.net/gentoo " LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/mnt/xfs/tabby/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdr cleartype cli consolekit cracklib crypt cups cxx dbus dri dts dvd dvdr eds emboss encode evo exif fam firefox flac fortran gdbm gif gnome gnome-keyring gpm gstreamer gtk hal iconv ipv6 jpeg laptop lcms ldap libnotify mad mikmod mmx mmxext mng modules mp3 mp4 mpeg mudflap multilib ncurses networkmanager nls nptl nptlonly ogg opengl openmp pam pango pcre pdf perl png policykit ppds pppd pulseaudio python qt3support readline samba sdl session spell sse sse2 ssl startup-notification svg sysfs tcpd threads tiff truetype unicode usb vorbis x264 xcb xml xorg xulrunner xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev joystick synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-2" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="vesa radeon radeonhd fglrx" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Also, is there some way to call out where the masked package is trying to be installed (i.e. / or /testroot)? I see this information at the -av prompt, but not when something is masked.
(In reply to comment #5) > Prefixing things with $(PORTAGE_CONFIGROOT) looks to be an excellent solution. > I am concerned with the following... When I emerge --root=/mnt/xfs/tabby > --config-root=/mnt/xfs/tabby --info, CONFIG_PROTECT="/etc ..." does that mean > /etc or /mnt/xfs/tabby/etc? Paths in CONFIG_PROTECT paths are evaluated relative to --root, so /etc in CONFIG_PROTECT evaluates to /mnt/xfs/tabby/etc. (In reply to comment #6) > Also, is there some way to call out where the masked package is trying to be > installed (i.e. / or /testroot)? I see this information at the -av prompt, but > not when something is masked. We can easily add support for that in the show_masked_packages() function.
(In reply to comment #7) > (In reply to comment #6) > > Also, is there some way to call out where the masked package is trying to be > > installed (i.e. / or /testroot)? I see this information at the -av prompt, but > > not when something is masked. > > We can easily add support for that in the show_masked_packages() function. There's a fix here, to show the ROOT once before show_masked_packages() is called: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=08aaf2185ee403b18cd9f9009201475ea3f26ce6
(In reply to comment #4) > (In reply to comment #3) > > it used shell syntax then it could look like this: > > > > [usersets] > > class = portage.sets.files.StaticFileSet > > multiset = true > > directory = ${PORTAGE_CONFIGROOT}/etc/portage/sets > > Sounds fair. Thanks! > We've had something like this since bug 298141: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=15f0c600dd226561c5345d813b3e9d6af21b41ee
*** This bug has been marked as a duplicate of bug 298141 ***
