Summary: | Better handling of einfo-output | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Olav Kolbu <gentoo> |
Component: | Core | Assignee: | Daniel Robbins (RETIRED) <drobbins> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | david, elcondor, henryk |
Priority: | High | ||
Version: | 2.0 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Olav Kolbu
2002-06-25 07:14:52 UTC
*** Bug 4943 has been marked as a duplicate of this bug. *** When i first thought about this, i thought about config file system. It would say that you have this and this many unread infos in queue. The "info-files" would be stored as ebuild-##.##.##.info files in a dedicated directory. And when read with a program like etc-update, you would have an option to delete the file. This has at least one problem that i can come up right now: If ebuild informs about errors with einfo (if einfo output is hidden, wouldn't want to read about error messages through that service.). Like Quake2 -ebuild does (informs if there are no output support). This could be solved with different command for outputting errors. Error messages would ofcourse be in different colors and all. Wouldn't it be useful to let portage show all the einfos at the end of an emerge 'session', like is done with rsync? Einfos are supposed to give important information, so the user will probably want to see it anyway. So basically it will be more automatic. I guess portage could log all the einfos to a file for each session and print the file at the end? *** Bug 11137 has been marked as a duplicate of this bug. *** |