Summary: | [Future EAPI]: Filter XDG / DISPLAY variables from the ebuild environment | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Mike Gilbert <floppym> |
Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dev-portage, esigra, gnome, gstreamer, jlec, jrmalaq, mgorny, nikoli, pacho, reto.gantenbein, sam, truedfx, tsmksubc |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=300867 https://bugs.gentoo.org/show_bug.cgi?id=444568 https://bugs.gentoo.org/show_bug.cgi?id=567192 |
||
Whiteboard: | in-eapi-7 | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 174380, 499202, 531596, 577704, 584242 |
Description
Mike Gilbert
2014-01-26 00:08:59 UTC
*** This bug has been marked as a duplicate of bug 444568 *** Actually, I would say that filtering the variables might not need an EAPI change. Current ebuilds cannot rely on them having any specific value, so it would be perfectly acceptable for Portage to unset them. (In reply to Mike Gilbert from comment #2) > Actually, I would say that filtering the variables might not need an EAPI > change. Sure it does. Otherwise things will work in Portage but break in other package managers. What I fail to see (also in bug 444568) is how XDG_* are different from other variables (like TEXMF*)? Usually such things are better handled at the ebuild/eclass level, because the package manager cannot foresee all eventualities. PMS defines very few variables like HOME and TMPDIR, and I think we should leave it at this. Honestly? I think the problem is that we're doing opt-out here, and we won't ever be able to predict all the ways random tools will get influenced by user's environment. IMO PM should scrub the environment completely, only setting the sane build-specific variables and maybe whatever's in env.d. Of course, this would make it impossible for our users to hack stuff like they currently do. That's a trade-off to consider. If we want to scrub the environment, we should just create one single eclass that handles all the possibilities. Otherwise, it's just wasting developers' time guessing which variables are actually used by which tools in which versions... (In reply to Michał Górny from comment #4) > IMO PM should scrub the environment completely, only setting the sane > build-specific variables and maybe whatever's in env.d. Scrubbing the environment would be throwing the baby out with the bath-water. > Of course, this would make it impossible for our users to hack stuff like > they currently do. That's a trade-off to consider. You rely on such "hacks" in your own eclasses. EVCS_OFFLINE is one example. To be fair, the baby is a large part of the reason that the bath water is so messy, so maybe a dead baby isn't necessarily a bad thing here... ECVS_OFFLINE and the like can easily be handled by allowing the user to set environment variables explicitly in a bashrc. It's variables leaking in from the wider environment that are the problem, not things that have been put there on purpose. (In reply to Ulrich Müller from comment #3) > (In reply to Mike Gilbert from comment #2) > > Actually, I would say that filtering the variables might not need an EAPI > > change. > > Sure it does. Otherwise things will work in Portage but break in other > package managers. As I mentioned on the list; the standard doesn't define the behavior, so we are free to pick whatever behavior we want for Portage. If ebuild authors rely on undefined behavior, well that is their problem; they should author ebuilds that follow the standard. > > What I fail to see (also in bug 444568) is how XDG_* are different from > other variables (like TEXMF*)? Usually such things are better handled at the > ebuild/eclass level, because the package manager cannot foresee all > eventualities. > > PMS defines very few variables like HOME and TMPDIR, and I think we should > leave it at this. (In reply to Ciaran McCreesh from comment #6) > To be fair, the baby is a large part of the reason that the bath water is so > messy, so maybe a dead baby isn't necessarily a bad thing here... > ECVS_OFFLINE and the like can easily be handled by allowing the user to set > environment variables explicitly in a bashrc. It's variables leaking in from > the wider environment that are the problem, not things that have been put > there on purpose. Just to be clear, I don't mind the environment variables leaking as bash variables to the ebuild. However, they should not be exported there. This filtering would also help on puntual bug reports we get related with sporadic failures because of different settings in variables like "DISPLAY" or DBUS* Also, having variables like DISPLAY kept have some side effects like some tests being able to open windows if people is compiling from a terminal (instead of failing or relying on virtualx eclass) Regarding whether this belongs to portage or PMS... well, if finally needs PMS updating maybe could be a good candidate for eapi6 :) @pms-bugs, could this be considered for eapi6? Either the cleaning of all environment variables (and then relying on a eclass appending the needed ones) or cleaning the known variables that need to be reset (as can be seen in many of the existing ebuilds and eclasses...). In PMS section 11.1 "Defined Variables" <http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-11800011.1> we already have this: GZIP, BZIP, BZIP2, CDPATH, GREP_OPTIONS, GREP_COLOR and GLOBIGNORE must not be set. I think the least intrusive action would be to extend this blacklist. So far we have: XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_RUNTIME_DIR Since EAPI 6 will introduce eapply(), the following might be added too (perforce is mostly historical, but patch-2.7.1 still supports the variables): P4CONFIG, P4PORT, P4USER Anything else? We are having problems also with DBUS_SESSION_BUS_ADDRESS and DISPLAY being set to random values depending on each setup, then, they should probably be added to that blacklist to get the "unset" by default. The problem is that we are finding offending variables when we hit the problems and sometimes they are a bit hard to find (sometimes we get a segmentation fault on a test and, after a long time, we notice it was caused by a wrong DBUS_SESSION_BUS_ADDRESS ...) Then, I think that maybe would be better to use the "inverse" logic, I mean: set the set of variables we know what values they need to have and drop all the others. That would make all a bit more predictable as we all would hit the same errors/problems and we would then be able to set the variables to the proper values for all people. With current situation each user has a different environment and it ends up being hard to figure out what is the concrete offending variable (I remember the old bug 300867 : some people were unable to build webkit-gtk as they were getting "argument list is too long" errors because "something" in their exported variables... but we weren't ever able to know what was the exact offending variable). My suggestion would then be something like: - Make PMs unset all variables except a minimum (probably the ones defined in http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-11800011.1 ) - Have an environment.eclass that would allow all of us to set there the variables to the desired values. For example, for XDG_* variable we need to unset the previous random value and set it to a known value under ${T} to prevent sandbox errors due to fallbacks to "real" directories if not defined. -> The advantage of having the environment.eclass as an eclass is that we can update it when needed without needing to wait for an eapi bump. One problem with that approach is the usual with eclasses, that we would need to inherit that eclass on a lot of packages... but maybe that could be solved if we would finally have a set of "special" eclasses that are inheritted always when eapi >= 6 (or the version that implements this finally) and environment.eclass was one of them Anyway, this is only a suggestion, I don't know much about PMS and then it's likely there are some drawbacks I haven't noticed due to that :) If we would introduce an eclass, couldn't it by itself empty the environment? But I guess this takes us back to comment #3: > Usually such things are better handled at the ebuild/eclass level, because > the package manager cannot foresee all eventualities. In that case, what is the advantage of still allowing to have random and unpredictable variable values "by default"? (In reply to Pacho Ramos from comment #15) > In that case, what is the advantage of still allowing to have random and > unpredictable variable values "by default"? You never know what variable might be useful. By leaving it to the ebuild/eclasses to use env -i when necessary, it allows for much more flexibility. But because of that, we cannot let each run to have a different set of variables around. Then, from my point of view, would be much more predictable to start with an empty environment + some variables that need to be set always (I guess the usual PATHs and other variables listed as "defined" in http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-11800011.1 ). But ebuilds shouldn't rely on the other variables because they will be set to different values depending on the setup (In reply to Pacho Ramos from comment #17) > But because of that, we cannot let each run to have a different set of > variables around. Then, from my point of view, would be much more > predictable to start with an empty environment + some variables that need to > be set always (I guess the usual PATHs and other variables listed as > "defined" in http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-11800011.1 ). Why not do this with env -i and add "some variables that need to be set" via env arguments? > But > ebuilds shouldn't rely on the other variables because they will be set to > different values depending on the setup If you want to do that, use env -i to call emerge. That way, it's still possible to pass in special variables that may be needed, such as for SSH_AUTH_SOCK for live ebuilds that need to fetch sources via ssh. (In reply to Zac Medico from comment #18) > (In reply to Pacho Ramos from comment #17) [...] > Why not do this with env -i and add "some variables that need to be set" via > env arguments? I am not against that, maybe I misunderstood something sorry. The point I am trying to explain is that, if PM doesn't clean the environment, each ebuild will behave differently depending on: - It manually cleaning the environment - It inheritting an eclass doing that work - ... An example I have seen some times: some package tests rely differently depending on DISPLAY being set or not, then: - If user/developer tends to run them from an xterminal test will work ok - If user/developer run emerge from a console they will die In other cases I have also seen some tests opening random windows while I am doing anything because they find a DISPLAY and they use it. And there are more different examples depending on each variable, for example the DBUS_SESSION_BUS_ADDRESS has different effect depending on each package/test, on it being set to a wrong value or... Then, I would stop letting ebuilds to rely on that variables being set to unknown values and, instead, have them dropped *or* set to known safe values (for DISPLAY and DBUS_SESSION_BUS_ADDRESS they should be unset, for XDG_* they need to point to ${T} to prevent sandbox errors). Well, re-reading all the thread again I am suggesting nearly the same as comment #4. Personally, I see the proposal of PM cleaning environment + 1 eclass that is inheritted always (to set known variables to proper values) as the one with more "prons". For example for bug 534582 => we now need to go to every single reverse dep to manually clean environment and set XDG_ to their proper values. And that is only one example for the XDG_ variables, there are multiple more examples involving other variables depending on their values changing on every setup :/ (In reply to Zac Medico from comment #18) [...] > If you want to do that, use env -i to call emerge. That way, it's still > possible to pass in special variables that may be needed, such as for > SSH_AUTH_SOCK for live ebuilds that need to fetch sources via ssh. Wouldn't be possible to get that known "locally set" variables exported by that eclass (for example having them in a specified place at /etc and then the eclass taking care to pass its values to the build? That would cover this "feature" too :| (In reply to Pacho Ramos from comment #19) > The point I am trying to explain is that, if PM doesn't clean the > environment, each ebuild will behave differently depending on: > - It manually cleaning the environment > - It inheritting an eclass doing that work > - ... That's a result of naive ebuild/eclass writing. These kinds of problems are easily solved by applying env -i liberally. > An example I have seen some times: some package tests rely differently > depending on DISPLAY being set or not, then: > - If user/developer tends to run them from an xterminal test will work ok > - If user/developer run emerge from a console they will die > > In other cases I have also seen some tests opening random windows while I am > doing anything because they find a DISPLAY and they use it. > > And there are more different examples depending on each variable, for > example the DBUS_SESSION_BUS_ADDRESS has different effect depending on each > package/test, on it being set to a wrong value or... > > Then, I would stop letting ebuilds to rely on that variables being set to > unknown values and, instead, have them dropped *or* set to known safe values > (for DISPLAY and DBUS_SESSION_BUS_ADDRESS they should be unset, for XDG_* > they need to point to ${T} to prevent sandbox errors). There's no one-size-fits-all solution. So ebuilds/eclasses need to apply env -i when appropriate. > Well, re-reading all the thread again I am suggesting nearly the same as > comment #4. Personally, I see the proposal of PM cleaning environment + 1 > eclass that is inheritted always (to set known variables to proper values) > as the one with more "prons". For example for bug 534582 => we now need to > go to every single reverse dep to manually clean environment and set XDG_ to > their proper values. > > And that is only one example for the XDG_ variables, there are multiple more > examples involving other variables depending on their values changing on > every setup :/ And as always, the problem is naive ebuild/eclass writing. (In reply to Pacho Ramos from comment #20) > (In reply to Zac Medico from comment #18) > [...] > > If you want to do that, use env -i to call emerge. That way, it's still > > possible to pass in special variables that may be needed, such as for > > SSH_AUTH_SOCK for live ebuilds that need to fetch sources via ssh. > > Wouldn't be possible to get that known "locally set" variables exported by > that eclass (for example having them in a specified place at /etc and then > the eclass taking care to pass its values to the build? That would cover > this "feature" too :| I think using env -i is just as good, maybe better because the package manager doesn't have to get involved. Involving the package manager adds an extra layer of complexity. (In reply to Zac Medico from comment #21) > I think using env -i is just as good, maybe better because the package > manager doesn't have to get involved. Involving the package manager adds an > extra layer of complexity. How does one apply env -i to a bash function call (like emake)? What's that, Timmy? Your Ruby packages won't build unless you have twenty three obscure environment variables from the global environment that change between Gems releases set? (In reply to Mike Gilbert from comment #22) > (In reply to Zac Medico from comment #21) > > I think using env -i is just as good, maybe better because the package > > manager doesn't have to get involved. Involving the package manager adds an > > extra layer of complexity. > > How does one apply env -i to a bash function call (like emake)? Here's a way to do it with emake: MAKE="env -i ${MAKE}" emake For econf, you'd have to create a fake configure script that wraps the real configure script. Neither of these look very appealing, so perhaps we should add some built-in environment filtering support to functions like these, so that they apply env -i internally when desired. (In reply to Zac Medico from comment #24) > MAKE="env -i ${MAKE}" emake Recursive? (In reply to Ciaran McCreesh from comment #25) > (In reply to Zac Medico from comment #24) > > MAKE="env -i ${MAKE}" emake > > Recursive? It will work, but obviously it's not very appealing. I think we should build environment filtering support into our helpers. This also has the advantage that it prevents *profile* variables from interfering with the build! Arriving with the experience of debugging #506766, my opinion is that it would much better to generally clean the environment and only allow clearly defined variables (similar to sudo or ssh) to enter the build setup. This would be my expected behaviour of portage. As it can be seen in the above bug report, it's totally unpredictable what environment variables a build system might use in what (broken) way. Of course this doesn't speak so much for the individual build system, however I think portage should use a more isolated build environment so that the build process is better repeatable and the users can be protected from such undefined behaviour. Without my digging, I don't think, that the mentioned bug would ever been resolved. Of course this was a very individual case but from a naive gentoo user's point of view, I can't see, why this was my fault (as it was mentioned in the report). A random undocumented user configuration, even when it's the root user, definitely shouldn't influence the build process in such an interruptive way. Look at the other side -- some tools simply need passing some environment variables. Think of distcc, for example. We don't want to add exclusions to the PMS every time we hit something. even though I am a proponent of the eclass camp, I must admit that we would probably be better off if we had a clean env with a whitelisted set of variables added. This whitelist may contain only what is actually being used by the package manager. Not sure if it would need any kinds of extension mechanism as long as PM reminds env across phases like it does nowadays. (In reply to Zac Medico from comment #21) [...] > I think using env -i is just as good, maybe better because the package > manager doesn't have to get involved. Involving the package manager adds an > extra layer of complexity. I don't see how it can be better as we would still need to add "env -i" + setting all the needed variables in tons of different ebuilds and eclasses... and also change ebuilds to use that eclasses. (In reply to Michał Górny from comment #28) > Look at the other side -- some tools simply need passing some environment > variables. Think of distcc, for example. We don't want to add exclusions to > the PMS every time we hit something. Couldn't that be done with that general "environment.eclass" that could be inheritted always in a newer eapi and, as it's still an "eclass" (even being "special" as is inheritted always) allow us to modify it do add new environment variables? (In reply to Pacho Ramos from comment #30) > (In reply to Zac Medico from comment #21) > [...] > > I think using env -i is just as good, maybe better because the package > > manager doesn't have to get involved. Involving the package manager adds an > > extra layer of complexity. > > I don't see how it can be better as we would still need to add "env -i" + > setting all the needed variables in tons of different ebuilds and > eclasses... and also change ebuilds to use that eclasses. Your proposed solution doesn't account for possible interference from variables exported by the profile or config files such as make.conf, though. If we integrate environment filtering into the ebuild helpers, then we have a solid solution. If you're concerned about code duplication, then you should use eclasses for code sharing. Is not possible to make PM to load all the variables from profiles and the defined config files after cleaning the environment? I guess the problem is that it's relying on them being set in previous environment and not explicitly loading them? :/ (In reply to Pacho Ramos from comment #32) > Is not possible to make PM to load all the variables from profiles and the > defined config files after cleaning the environment? The PM can start with an clean environment, then include all the variables from the profiles and config files. However, as long as those variables are exported, they pose a risk of interference with the build system. This is why I have suggested that ebuild helpers filter the environment, so that calls to the underlying build system do not necessarily see any exported variables that you do not want them to see. > I guess the problem is > that it's relying on them being set in previous environment and not > explicitly loading them? :/ No, it's nothing like that. It's actually very easy for the PM to control what variables are exported. However, there's no guarantee how the underlying build system will behave if it sees those exported variables. If there is consensus that the course of action should be what I have outlined in comment 12, then I'll put this onto the roadmap for EAPI 7. That is, add the following variables to the blacklist: XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_RUNTIME_DIR (In reply to Ulrich Müller from comment #34) > If there is consensus that the course of action should be what I have > outlined in comment 12, then I'll put this onto the roadmap for EAPI 7. > > That is, add the following variables to the blacklist: > XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_RUNTIME_DIR There is no consensus. This is fixing a specific issue that we noticed long time ago and that has grown to enormous size today in some undefined future, with no lesson taken for the future. So in a few months time, we're going to see another major problem like this, and we're going to discuss it all, create another eclass, then add three variables in EAPI 8 with no lesson taken... What we should do instead is scrub *all* environment variables, except for PM-defined special variables, contents of make.defaults, variables explicitly set by configuration files and explicitly listed pass-through variables. We also should add the list of explicit pass-through envvars to profiles, so developers can easily update that as needed to make eclasses/quirks function. Alternatively, extend the blacklist with a profile-defined variable. But still, that would be constantly chasing any possible interferences. (In reply to Michał Górny from comment #35) > There is no consensus. Sure, we can make a mountain out of a molehill and continue discussing this for another two years, instead of simply fixing the issue at hand (which is clearly defined in the Summary). This is not WORKFORME for my case (and I doubt from other gnome team members that are now suffering issues like bug 567192 caused by unproper variables being inheritted and failing in some random ways) Of course I prefer the mgorny approach of cleaning all environment to prevent errors like this... but if that cannot be done (I think there were another bug for that also stalled for a long time) we NEED at least to mimic xdg.eclass behavior to not need to randomly use it when someone catches an issue related with this concrete variables As I recall Brian designed pkgcore with a whitelist system rather than the blacklist system currently used by portage. I think it would make sense to update pms to require a whitelist system. That would fix most of these types of issues. Albeit, there would be some currently semi-auto-magic behavior that would have to be fixed in some systems. As I recall there are occasional pkgs that pkgcore fails to build and install correctly due to some variables not being whitelisted. (In reply to Brian Dolbec from comment #38) > As I recall Brian designed pkgcore with a whitelist system rather than the > blacklist system currently used by portage. > > I think it would make sense to update pms to require a whitelist system. > That would fix most of these types of issues. Albeit, there would be some > currently semi-auto-magic behavior that would have to be fixed in some > systems. As I recall there are occasional pkgs that pkgcore fails to build > and install correctly due to some variables not being whitelisted. It should be a blacklist, because a whitelist has several problems. First, currently all variables are being passed, so any issues with that should be visible now, so we should have an approximate picture where the problems are. Whereas we don't have any idea what problems a complete blocking of the environment would cause. Second, and more importantly, blacklists can be stacked. So there could be a global blacklist in the profile, and in addition some variables could be blocked on the ebuild level, if they cause problems for one package only. OTOH, a whitelist must necessarily be global, and there is no way to whitelist additional things for one ebuild or eclass. I fear that such a global whitelist would soon grow to a large and unmaintainable mess. (For example, it would have to contain most of the variables defined in /etc/env.d/.) The blacklist could be defined in a variable like UNSET_VARS in make.defaults. Presumably, only a new EAPI, but no profile EAPI bump would be necessary. *** Bug 598547 has been marked as a duplicate of this bug. *** Copied from bug 598547: Michał Górny 2016-10-30 16:32:23 UTC Split from bug #499288. The idea is to have a variable specifying blacklist of environment variables for profiles. The variable would be stacked, and the resulting value would be used to unset environment variables that are known to break stuff, such as XDG_* or DISPLAY. For the concrete case of XDG_ vars... I am not sure if it is enough to simply unset the vars, but also to export them to the proper places for not having sandbox issues (bug 444568 and the thing xdg.eclass is doing) (In reply to Pacho Ramos from comment #42) > For the concrete case of XDG_ vars... I am not sure if it is enough to > simply unset the vars, but also to export them to the proper places for not > having sandbox issues (bug 444568 and the thing xdg.eclass is doing) Couldn't that part be handled in an eclass? (In reply to Pacho Ramos from comment #42) > For the concrete case of XDG_ vars... I am not sure if it is enough to > simply unset the vars, but also to export them to the proper places for not > having sandbox issues (bug 444568 and the thing xdg.eclass is doing) What is the exact issue? Libraries not respecting HOME and querying passwd instead? sandbox violations due to the fallback to /root/. when nothing is set (In reply to Pacho Ramos from comment #45) > sandbox violations due to the fallback to /root/. when nothing is set That doesn't answer my question. Where does it get /root from? I was sure this was explained in a bug but I could not find it. It is: https://bugs.gentoo.org/show_bug.cgi?id=444568#c5 It depends on the packages, but usually they tend to create files on ~/ or even / when the variables are not set a lot. That is the reason we ensure the variables are exported like XDG spec says: https://bugs.gentoo.org/show_bug.cgi?id=444568#c0 and point them to writable places by portage The spec clearly says that if the variables are empty or unset, the applications are supposed to use defaults equal to $HOME subdirectories. So if anything doesn't do that, we should really report a bug instead of working it around. Especially that as you point out, a few common libraries are responsible for this anyway. Yeah, I guess we could force the filtering from PMS and rely on the eclass for the remaining broken packages (until upstreams care :/). I am not sure of other members of gnome or gstreamer teams (in this case for dev-lang/orc, that looks to be the most relevant case of package failing when none is set) will have more "updated" information about this issue. *** Bug 567474 has been marked as a duplicate of this bug. *** It seems the one about unsetting DISPLAY was closed as a dupe to be handled here (updating summary to find the bug more easily) Ok, so here's my idea. As I see it, it's easy to implement and as such could be suitable for EAPI 7 still, unless you believe we need to discuss it till death without actually solving any problem. Let's add ENV_BLACKLIST variable that can be set in make.profile. When processing an EAPI 7 package, the package manager builds a blacklist from ENV_BLACKLIST contents. The blacklist is constructed by iterating over space-separated strings in the variable, so that: - if a string does not start with a hyphen ('-'), it is interpreted as a variable fnmatch pattern, and all currently set variables matching it are added to the blacklist, - if a string starts with a hyphen ('-'), it is stripped and the remainder is interpreted as a variable fnmatch pattern, and all currently set variables match it are removed from the blacklist. After constructing the blacklist, the package manager guarantees that all variables listed in it will have their values unset. Examples: ENV_BLACKLIST="" -> full pass-through allowed (but see below) ENV_BLACKLIST="DESKTOP XDG_*" -> strip 'DESKTOP' and everything starting with 'XDG_' (though I'd discourage wildcards like this) ENV_BLACKLIST="* -FOO -BAR" -> strip everything except for 'FOO' and 'BAR' Most notably, this has the following implications: 1. If ENV_BLACKLIST is unset (old profiles, custom profiles), the behavior doesn't change. 2. The spec only requires blacklisting specific variables. The remaining variables can be passed through via blacklist/whitelist as PM logic and/or configuration permits which allows what different PMs do. 3. We start with blacklist which is easier to implement without breaking stuff. We may eventually switch to whitelist as we see fit. 4. I think we can do this without bumping profile EAPI since the extra variable does not affect anything but ebuilds with the new EAPI. 5. fnmatch patterns aren't really necessary but they provide the '*' for whitelist variant, and are cleaner than special casing '*'. It looks ok to me :) (In reply to Michał Górny from comment #52) > 5. fnmatch patterns aren't really necessary but they provide the '*' for > whitelist variant, and are cleaner than special casing '*'. I strongly disagree about this part. There should be a blacklist only, for the reasons stated in comment #39. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=a5e02c92fd72aad6eb9031cdc04f634543ebdd15 commit a5e02c92fd72aad6eb9031cdc04f634543ebdd15 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2018-02-21 09:54:18 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-03-11 11:43:41 +0000 Support ENV_UNSET for EAPI 7 Bug: https://bugs.gentoo.org/499288 bin/eapi.sh | 4 ++++ bin/ebuild.sh | 6 ++++++ pym/_emerge/actions.py | 4 ++-- pym/portage/const.py | 3 ++- 4 files changed, 14 insertions(+), 3 deletions(-)} The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=7e94b3912fff029b0201ec803b15c69146ac84bb commit 7e94b3912fff029b0201ec803b15c69146ac84bb Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2017-11-10 13:51:41 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2018-03-31 15:30:43 +0000 EAPI 7 has ENV_UNSET. Thanks to mgorny for providing the initial wording. Bug: https://bugs.gentoo.org/499288 eapi-differences.tex | 4 ++++ ebuild-env-vars.tex | 2 ++ profile-variables.tex | 23 +++++++++++++++++++++++ 3 files changed, 29 insertions(+)} *** Bug 127560 has been marked as a duplicate of this bug. *** |