When I do an emerge -pvuDN world and see some critical system or application updates are available - ie, portage, python, a critical server app, etc - I'd like to be able to see the einfo messages that *would* be output after a successful emerge, but *before* I actually perform the emerge. This would allow me to judge the potential for breakage *before* it happens. Personally, I'd like to see these messages simply by using an additional switch to emerge, but I was told that this would not happen, but that it was possible it could be done with a tool like equery, so here I am... :) Here's the initial bug I opened for adding this to emerge: http://bugs.gentoo.org/show_bug.cgi?id=281248 See this forum thread for the discussion that lead to the first bug/feature request, as well as a working script that attempts to implements this functionality: http://forums.gentoo.org/viewtopic.php?p=5930125#5930125 Thanks for Gentoo!
(In reply to comment #0) > When I do an emerge -pvuDN world and see some critical system or application > updates are available - ie, portage, python, a critical server app, etc - I'd > like to be able to see the einfo messages that *would* be output after a > successful emerge, but *before* I actually perform the emerge. This would allow > me to judge the potential for breakage *before* it happens. This is really the use case GLEP 42: Critical News Reporting[1] was designed to take care of. I would say it's just not widely enough used yet. I guess I'm saying I'd rather not write more code to solve a problem that's already been fixed, but if everyone thinks this is a good idea, maybe equery changes (new in gentoolkit-0.3.0) would be a good home for it. [1] http://www.gentoo.org/proj/en/glep/glep-0042.html
Yeah... I just checked, and there is very little in my /usr/portage/metadata/news/ dir... and nothing about any of the 12 update candidates ready for my system... So, hopefully, if this isn't too much work, it can provide a way of at least easily previewing the einfo of a package without actually having to install the package or manually grep the ebuild. Thanks for considering it...
If we put this into equery, we need to be very specific that we are making a best guess and that the information might not be accurate. The only way to know exactly what will be printed is to actually execute the ebuild through emerge which defeats the purpose of this feature.
I don't think this really fits into gentoolkit territory since the issue has been addressed in a number of ways: * you can read eselect news to make sure there aren't any known breakages; * you can use 'equery changes pkgname' from ~gentoolkit-0.3.0 to get an overview of the changes in the latest installable package. This sometimes includes a bug reference that you can track; * you can use 'less $(equery w pkgname)', then type '/ewarn<enter>' to highlight all ewarn lines, and use 'n' and 'N' to skip forward and backward between them; That combined with common sense stuff like waiting for a few days before upgrading critical apps should keep most people out of trouble. If there's an increasing demand for this kind of thing down the road we can reopen and reconsider (but in that case I think GLEP 42 will have failed). For now, closing as WONTFIX. Thanks very much for your input, though.
