Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 114723 - new tool request for displaying the effects of package.mask, package.unmask, package.use, etc. for easy debugging
Summary: new tool request for displaying the effects of package.mask, package.unmask, ...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Tools (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage Tools Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-07 03:13 UTC by Gregor Mückl
Modified: 2011-07-20 06:34 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gregor Mückl 2005-12-07 03:13:35 UTC
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).
Comment 1 Jason Stubbs (RETIRED) gentoo-dev 2005-12-07 04:46:56 UTC
Could you describe what your request a bit more thoroughly please? Are you 
hoping for output similar to --debug? Something else? 
Comment 2 Gregor Mückl 2005-12-07 05:07:25 UTC
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). 
 
Comment 3 Jason Stubbs (RETIRED) gentoo-dev 2005-12-07 05:14:52 UTC
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- 
 
Comment 4 Gregor Mückl 2005-12-07 08:41:31 UTC
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.  
Comment 5 Zac Medico gentoo-dev 2005-12-07 09:02:19 UTC
(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.
Comment 6 Marius Mauch (RETIRED) gentoo-dev 2005-12-07 09:06:14 UTC
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.
Comment 7 Gregor Mückl 2005-12-07 11:28:27 UTC
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) 
Comment 8 Marius Mauch (RETIRED) gentoo-dev 2005-12-07 11:33:40 UTC
So a complete config analyzer ... definitely outside the scope of emerge.
Comment 9 Gregor Mückl 2005-12-07 12:12:34 UTC
Then build it into emaint. 
Comment 10 Alec Warner (RETIRED) archtester gentoo-dev Security 2005-12-07 12:30:44 UTC
(In reply to comment #9)
> Then build it into emaint. 

Patches are always welcome :)
Comment 11 Alec Warner (RETIRED) archtester gentoo-dev Security 2005-12-07 19:03:49 UTC
This should probably be tools and not in portage proper, re-assigning.
Comment 12 Simon Stelling (RETIRED) gentoo-dev 2006-04-15 07:11:21 UTC
(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
Comment 13 Brian Dolbec (RETIRED) gentoo-dev 2011-07-20 06:34:13 UTC
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.