Summary: | [PATCH] portage exports too many variables, breaking Makefiles using them | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Harald van Dijk (RETIRED) <truedfx> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | falco, pms |
Priority: | High | ||
Version: | 2.1 | ||
Hardware: | All | ||
OS: | NetBSD | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=721088 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | patch to use portage-specific names for the exported vars |
Description
Harald van Dijk (RETIRED)
2006-03-25 12:58:34 UTC
> 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 *** |