Summary: | sys-apps/portage: action_info support to log output to a file | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Magnus Granberg <zorry> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | kentnl |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Magnus Granberg
2013-05-06 21:31:43 UTC
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. |