Right now it is incredibly difficult to track down own mistakes when masking/unmasking packages or setting use-flags and keywords on individual packages because emerge remains totally silent about how it handles these files. Therefore I strongly suggest that you add a new command line parameter to emerge that actually causes it to display how portage interprets these files at different layers (portage, portage overlays, user).
Could you describe what your request a bit more thoroughly please? Are you hoping for output similar to --debug? Something else?
What I'd like to see is some concise output on what information portage actually obtains from the files (e.g. lists of manually blocked ebuilds or ebuilds with extra use flags or different keywords). In the simplest form, it would be the information that was obtained by parsing these files, so that one can check if the the input is really understood by portage. A big bonus would be if there were a way to list all ebuilds that are affected by the given configuration (so that one can check how the given mask/unmask line really behaves, for example). In contrast, --debug does print little to no information on what emerge actually read from /etc/portage/package.*. It is no doubt useful output when developing ebuilds, but it is no use when you're trying to track down a configuration error in said files (which can unfortunately grow to considerable length).
Perhaps if you could provide an example of the sort of error that wasn't detected? Invalid atoms should be displayed for all files: # grep foo /etc/portage/package.mask <><fooasdf- # emerge | grep foo --- Invalid atom in /etc/portage/package.mask: <><fooasdf-
You're missing the point here. There is no confirmation if information from files like package.mask or package.unmask was used or specifically discarded (although syntactically correct) for a certain decision. Therefore I'd like to have a command that can provide e.g. an overview of indivdual packages (not just range of packages like >=dev-lang/swig-1.3.25) that are affected and how they are affected. This helps to get into the specifics of the configuration of a particular system (being involved with a couple of different gentoo installations it's easy to lose oversight over such details) and to check if portage actually will behave as intended or to get a hint why it won't. I'm looking for some more general approach here than just running emerge with a certain list of packages and getting informational output on these only. Maybe I'm just not explaining my point well enough here.
(In reply to comment #4) > You're missing the point here. There is no confirmation if information from > files like package.mask or package.unmask was used or specifically discarded > (although syntactically correct) for a certain decision. For example, when package.unmask accidentally overrides a setting in package.mask? Or, when two lines for the same atom in package.keywords or package.use causes the earlies line(s) to be discarded? It seems like a warning message would be nice in those cases.
No information is specifically discarded if it is syntactically correct. If you're referring to typing errors, that information is still kept, it just won't apply to any package. Please give an actual use case for this (including example contents of package.* and example output), otherwise this will be closed as we can't guess what you're after.
You're thinking inside a very small box, it seems. Let's try a more formal approach for what I want. What I want is a tool that outputs for example: 1. For each entry in each package.mask file considered by emerge, it outputs a list of individual ebuilds (including version number) that are affected. 2. For each entry in each package.unmask it does the same. 3. If an entry in package.mask, package.unmask, packge.use or package.keywords does not apply to any available ebuild, a warning message is generated 4. If there is an entry in any package.mask or package.unmask file that includes a version number, but maskes all available versions of this ebuild, a notice is generated. 5. If there is an entry in package.use that specifies use flags which do not apply to the ebuild in question, a warning message is generated. I do not know if emerge is the right place for that feature. Maybe it should rather go into emaint or some other tool. But from my point of view this would be a very useful tool as I'm working a range of boxes with sometimes wildly differnt setup details and I am required to provide both a rock-solid base system with up to date application on top of that. So I can't use testing as it is broken far too often and stable sometimes is too old for my user's needs, which forces me to pull of all kinds of stunts with masks and use flags. And I'm not the only one here who has this particular problem. (And I have a specific example of an entry in package.mask being ignored, but this report serves a different purpose, so I'm not going into details here)
So a complete config analyzer ... definitely outside the scope of emerge.
Then build it into emaint.
(In reply to comment #9) > Then build it into emaint. Patches are always welcome :)
This should probably be tools and not in portage proper, re-assigning.
(In reply to comment #11) > This should probably be tools and not in portage proper, re-assigning. Apparently it didn't get reassigned. Doing that now :P
brian@big_daddy ~ $ emerge -vp portage These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U *] sys-apps/portage-9999 [8888] USE="doc epydoc (ipc) less%* -build -python2 -python3 (-selinux)" 0 kB [1=>0] emerge now will display info from /etc/portage/package.[keywords,mask, unmask] Note the * after the U indicating the /etc/portage/package.keywords override. It may not do everything desired of this bug, but should help. As for a tool for complete system analysis, gentoolkits enalyze has some of this ability now, and I plan to add more modules & reports. Currently you can get complete reports on your installed pkg db for USE flags, keywords. It also has a rebuild module that can produce a replacement package.use and package.keywords file. Eventually it will have enough library routines to do complete data validation on the package.* files to identify outdated entries, etc.
