portage exports FILESDIR and some other variables that should only be used by ebuilds and eclasses. This can break when a Makefile, script, or anything, uses variables with the same name. There shouldn't be any reason for anything other than functions called by ebuilds or eclasses to check the portage-provided values, so please un-export them. --- portage-2.1_pre7/bin/ebuild.sh +++ portage-2.1_pre7/bin/ebuild.sh @@ -1391,7 +1391,7 @@ unset E_IUSE E_DEPEND E_RDEPEND E_PDEPEND for x in T P PN PV PVR PR CATEGORY A EBUILD EMERGE_FROM O PPID FILESDIR PORTAGE_TMPDIR; do - [[ ${!x-UNSET_VAR} != UNSET_VAR ]] && declare -r ${x} + [[ ${!x-UNSET_VAR} != UNSET_VAR ]] && declare +x -r ${x} done # Need to be able to change D in dyn_preinst due to the IMAGE stuff [[ $* != "preinst" ]] && declare -r D If there is a reason why some of these must be exported (I don't see any; the ones that must be are exported explicitly later), would you please export only those, and not everything? Portage 2.1_pre7 (!/usr/overlay/profiles/default-bsd/nbsd/3.0/x86, gcc-, unavailable, 3.0 i386) ================================================================= System uname: 3.0 i386 i386 Unknown Host Operating System dev-lang/python: 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: [Not Present] ACCEPT_KEYWORDS="x86 x86-nbsd ~x86 ~x86-nbsd" AUTOCLEAN="yes" CBUILD="i386-gentoo-netbsdelf3.0" CFLAGS="-march=athlon-tbird -O2 -pipe" CHOST="i386-gentoo-netbsdelf3.0" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/env.d" CXXFLAGS="-march=athlon-tbird -O2 -pipe" DISTDIR="/var/dist" FEATURES="autoconfig autopatch buildpkg cvs distlocks metadata-transfer noauto notitles sandbox sfperms sign strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="" PKGDIR="/var/pkg" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cvs/gentoo-x86" PORTDIR_OVERLAY="/usr/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86-nbsd 3dnow 3dnowext X bidi bitmap-fonts bzip2 cjk dlloader ftp gtk idn lynxkeymap mbox mmx mozdevelop mozsvg mp3 nls nntp nocxx ogg opengl pango png pop quicktime real sse sse2 ssl theora truetype truetype-fonts type1-fonts unicode vorbis xv xvid zlib elibc_NetBSD input_devices_keyboard input_devices_mouse kernel_NetBSD userland_BSD video_cards_ati" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LINGUAS, MAKEOPTS
> I don't see any Sorry, I missed that a few of them are needed by some scripts in /usr/lib/portage/bin which are not defined as functions. The problem still exists though. For those needed by the scripts, maybe it would be a better idea to export a variable with a less generic name for use by them, and declare an unexported variable with a short name for use by ebuilds. I will try to create a patch which does this.
Created attachment 83112 [details, diff] patch to use portage-specific names for the exported vars With this, VAR and PORTAGE_VAR are both defined, and ebuilds can use either. VAR is not exported, so it won't interfere with packages' Makefiles, and PORTAGE_VAR is exported for use by /usr/lib/portage/bin/*. There may still be more exported variables that would be better renamed, but getting rid of these would be a good start.
Is it suddenly breaking stuff with pre7 that worked alright with pre6? There were lot's of changes in the ebuild environment setup, so it's possible.
Might want to state what this is actually breaking before pushing for large scale var changes (that should probably be an eapi bump even).
Harald, care to reply on comments #3 and #4? CCing PMS people as this isn't a completely irrelevant detail.
I had originally answered on IRC, IIRC because I had no access to a web browser at the time. I'm not surprised it was forgotten. :) No, this wasn't something that had changed in portage, it was something I had run into with a new package. It was one part of the NetBSD base system (though I don't remember which part), which used a FILESDIR ?= ... construct in its Makefiles, causing portage's FILESDIR variable to be used. There was no way to unset it in the ebuild, not even in a subshell, because it was a read-only exported variable. env -u would be a way around it, except it's not supported on *BSD, which is especially a big problem for a *BSD base system ebuild. :)
*** This bug has been marked as a duplicate of bug 499288 ***
