Created attachment 686277 [details] bug exporting WGETRC into the running shell environment breaks fetching files with portage. Propositoion: unset/ignore the env var.
But it works if you point WGETRC to an actual file, which is readable by portage user, right?
(In reply to Ben Kohler from comment #1) > But it works if you point WGETRC to an actual file, which is readable by > portage user, right? Yes, it works when pointed to a file owned by portage.
It is possible that the user might intentionally set WGETRC when invoking emerge. I don’t see why we would add special treatment for this. I would not classify this as a bug, and I think this should be closed as invalid.
Since emerge is intended to pass through environment variables, it behaves as intended. Reassigning to base-system to in case there's any desire to do something about this WGETRC=/dev/null behavior.
> about this WGETRC=/dev/null behavior. It's not about the specyfic case of "/dev/null" only. I discovered this becasue I eport WGETRC for wget to use my own wgetrc but I did not expect it will also be picked up by wget used by portage.
I see from your log output that you are installing app-admin/sudo. If you run emerge using sudo, most environment variables will be unset, and that should resolve your problem.
(In reply to Mike Gilbert from comment #6) > I see from your log output that you are installing app-admin/sudo. If you > run emerge using sudo, most environment variables will be unset, and that > should resolve your problem. Heh, I just did this for example because I dont have sudo ;D I do su -l root and that's how I do stuff as root. Resolving this with using sudo is a rather controversial method.
Setting WGETRC to a certain value then being surprised that emerge's wget respects that, seems a bit odd to me.
(In reply to Ben Kohler from comment #8) > Setting WGETRC to a certain value then being surprised that emerge's wget > respects that, seems a bit odd to me. >CARGO_HOME Remember?
If you are going to use that to argue that NO variables from the calling environment should be respected ever, I'm going to have to disagree.
(In reply to Ben Kohler from comment #10) > If you are going to use that to argue that NO variables from the calling > environment should be respected ever, I'm going to have to disagree. Well, in my opinion WGETRC should be not respected or maybe the env var is would not be but it can be set in make.conf?
* or maybe the env var would not be but it can be set in make.conf?
As far as I know, the things we are using ENV_UNSET for, are things that might accidentally get automatically and cause problems. Not for blacklisting any variable that the user might explicitly set which could possibly cause an emerge failure.
(In reply to Ben Kohler from comment #13) > As far as I know, the things we are using ENV_UNSET for, are things that > might accidentally get automatically and cause problems. Not for > blacklisting any variable that the user might explicitly set which could > possibly cause an emerge failure. irc.freenode.#gentoo-moz.weechatlog:345:2020-08-28 22:27:50 xgqt Hey. with the CARGO_HOME env var exported tothe running shell firefox will try to install rust pkgs in that CARGO_HOME I reported the CARGO_HOME problem (on IRC) cause I have set it manually
You should not be doing that in the root emerge context. Stop doing these things.
I dare say this is a valid problem. There is no real reason why root wouldn't be allowed to set WGETRC in his environment. Since Portage uses wget internally and by default, it should be resilient to breakage caused by user's wgetrc contents or path mismatching its expectations. If I set root's WGETRC to a file that is readable by root, emerge really shouldn't fail because it tries to read that file using portage user's permissions.
If you want to propose an enhancement, please re-assign the bug back to dev-portage and send a patch. This is certainly not a "bug", and is not going to be addressed by any action base-system would take.
Raises the question of whether it's sane to let enviroment variables leak in by default.
(In reply to Zac Medico from comment #18) > Raises the question of whether it's sane to let enviroment variables leak in > by default. Exactly. Maybe a switch like --use-env should be introduced and when it is off env will be cleared and only stuff in make.conf will be used.
> This is certainly not a "bug", and is not going to be addressed by any action base-system would take. To expand on that: if a change in behavior in wget itself is desired, the upstream mailing list would be the place to propose it. I don't think we want to get into the business of changing its behavior via local patching. https://lists.gnu.org/mailman/listinfo/bug-wget
(In reply to Zac Medico from comment #18) > Raises the question of whether it's sane to let enviroment variables leak in > by default. Sadly, it's necessary by design. Otherwise, we'd have to maintain a huge whitelist of variables such as all eclass control variables, EXTRA_* stuff, etc.
Something like the --use-env option suggested in comment #19 will probably work. However, if it's not enabled by default then we'll break anything relying on the current behavior. I imagine that the breakage will probably be acceptable, but the change will need to be well documented in order to minimize confusion. We can add the option before we enable it by default, so that people can start using it before it becomes default.
(In reply to Zac Medico from comment #22) > Something like the --use-env option suggested in comment #19 will probably > work. However, if it's not enabled by default then we'll break anything > relying on the current behavior. I imagine that the breakage will probably > be acceptable, but the change will need to be well documented in order to > minimize confusion. We can add the option before we enable it by default, so > that people can start using it before it becomes default. Or just let it break? Inaction is also action ;) -A
