Make portage save the emerge --info to a file if we have --quiet. This feature can be good when tinderboxing so some code can save the info for the emerge package.
I think most people would just redirect the emerge output to a file like this: emerge --info > emerge_info.txt So, do you really want emerge to have built-in redirection support? Or do you just want an API change so that you can redirect the output of the action_info() function in pym/_emerge/actions.py?
(In reply to comment #1) > I think most people would just redirect the emerge output to a file like > this: > > emerge --info > emerge_info.txt > > So, do you really want emerge to have built-in redirection support? Or do > you just want an API change so that you can redirect the output of the > action_info() function in pym/_emerge/actions.py? Most a api change so it can be redirected. For i will mostly call action_info() from python code to get the needed info, if is from a file or a list is fine by me.
In #gentoo-portage today, Kent Frederic suggested to log emerge --info <pkg> to a file when the build starts. The for build failures, instead of saying "submit ${T}/build.log.gz", it could internally do: "zcat ${T}/build.log | cat - ${T}/einfo | gzip > ${T}/report.log.gz" or something along those lines.
(In reply to Zac Medico from comment #3) > In #gentoo-portage today, Kent Frederic suggested to log emerge --info <pkg> > to a file when the build starts. The for build failures, instead of saying > "submit ${T}/build.log.gz", it could internally do: "zcat ${T}/build.log | > cat - ${T}/einfo | gzip > ${T}/report.log.gz" or something along those lines. To clarify: I think things like variables and stuff that are "fixed" should be captured early, to reflect what the settings actually were when that package was compiled ( and can't be affected by changes in configure that may have happened while a large `emerge -uvatDN @world` was taking place ). But things like "which compiler, which version of make, etc" possibly need to be captured closer to the fail point, because those things *can* be switched out from underneath portage if the user does upgrades in a side thread. Though I think the best approach would be to record these values at the start, and then when an error occurs, re-calculate what is installed *at the time*, and then only report those that have changed _if_ they have changed. There will still be race conditions that invalidate the data, but keeping that window as small as humanly possible is a benefit.
