This is bad as we want to be able to have more proper information for the package itself, without package.env support we're providing only half-truths.
*** Bug 399551 has been marked as a duplicate of this bug. ***
*** Bug 421519 has been marked as a duplicate of this bug. ***
*** Bug 502540 has been marked as a duplicate of this bug. ***
*** Bug 533708 has been marked as a duplicate of this bug. ***
Hi, First of all, sorry for reviving a bug that's existed in Bugzilla for a whole decade. (In my defense, it's still open.) That said, I am unable to reproduce this bug for packages that emerge successfully. To test this, I created the following to override CFLAGS for app-shells/fish: /etc/portage/package.env/testenv app-shells/fish fish.conf /etc/portage/env/fish.conf CFLAGS="-O3" I then emerged the package, and after running emerge --info, the new CFLAGS *does* appear (amongst other output I've removed for the sake of brevity): # emerge --info app-shells/fish app-shells/fish-3.4.0::gentoo was built with the following: USE="doc nls -test" ABI_X86="(64)" CFLAGS="-O3" If anyone can provide an example where this doesn't work properly or if there's anything else I should've tested, please let me know.
Thanks to [Arfrever] in #gentoo-portage for providing some clarification on when this bug actually occurs. To make a long investigation short, and maybe provide a little bit of clarification on the underlying issue for future clueless folks like me: The "basic"/typical environment variables like CFLAGS, CXXFLAGS, etc. will have their package.env overrides reported correctly, but more uncommon ones like, say, PORTAGE_TMPDIR will not. These variables are pulled from /var/db/, but not every variable that can be set in make.conf (e.g. PORTAGE_TMPDIR) is recorded in vardb in the first place. If there's no record of one of these variables, then emerge --info has nothing to pull from. I don't know if expanding vardb to be more comprehensive(?) would be worth the effort or if that would even be the correct play. I also don't know if this is worth spending more time on, as it's a decade-old bug that hasn't seen a duplicate since 2014. Open to feedback; I'm pretty new here.
I would suggest that the reason there haven't been any new duplicate bugs is because this has been well indexed into google. People are easily able to find these bugs, see that the problem has been recognized and not post another duplicate bug. This would be nice to have, but I can always do something like ebuild ___.ebuild configure and go look at the files under /var/tmp/portage. I assume those files have what I need. TL;DR Again, this would be very nice to have, but workarounds exist.