I just want to throw out and discuss a pending change to gentoolkit.package.get_mask_status(). The problem: equery list and hasuse mask status isn't always an accurate representation of the current masking status of the package (see bug 269699) $ eix -e ruby * dev-lang/ruby Available versions: (1.8) [M]1.8.6_p114 1.8.6_p368 ~1.8.7_p160 (1.9) [M]~1.9.1_p129 [M]~1.9.1_p129-r1 {berkdb cjk debug doc emacs examples gdbm ipv6 rubytests socks5 ssl threads tk xemacs} Homepage: http://www.ruby-lang.org/ Description: An object-oriented scripting language # Notice eix shows 1.8.7_p160 as keyword masked (~) and all greater version # as hard masked ([M]) and keyword masked. Current versions of equery consider some things that are only keyword masked as hard masked (notice 1.8.7_p160): with gentoolkit-0.2.4.5: $ equery l -p -e ruby [ Searching for package 'ruby' in all categories among: ] * installed packages * Portage tree (/usr/portage) [-P-] [M ] dev-lang/ruby-1.8.6_p114 (1.8) [-P-] [ ] dev-lang/ruby-1.8.6_p368 (1.8) [-P-] [M~] dev-lang/ruby-1.8.7_p160 (1.8) [-P-] [M~] dev-lang/ruby-1.9.1_p129 (1.9) [-P-] [M~] dev-lang/ruby-1.9.1_p129-r1 (1.9) # Portage's internal masking status function, which is not currently used by # gentoolkit, proves eix is correct: $ python -c "import portage; print portage.getmaskingstatus('dev-lang/ruby-1.8.7_p160')" ['~x86 keyword'] $ python -c "import portage; print portage.getmaskingstatus('dev-lang/ruby-1.9.1_p129')" ['package.mask', '~x86 keyword'] The solution: use getmaskingstatus() to provide a more accurate masking status. # using getmaskingstatus: $ equery l -p ruby * Searching for ruby ... [-P-] [M ] dev-lang/ruby-1.8.6_p114 (1.8) [-P-] [ ] dev-lang/ruby-1.8.6_p368 (1.8) [-P-] [ ~] dev-lang/ruby-1.8.7_p160 (1.8) [-P-] [M~] dev-lang/ruby-1.9.1_p129 (1.9) [-P-] [M~] dev-lang/ruby-1.9.1_p129-r1 (1.9) It's way faster, too :) --- The only problem is that with the previous method (package.is_masked()), that function made a blind assumption that the ebuild still exists on the system. In a situation where a package was installed and then the ebuild was removed from the tree, is_masked would falsely return that the package was masked, even though it is installed (so not masked). getmaskingstatus() has a different approach to dealing with non-existant ebuilds, which is to traceback: $ equery l emeta * Searching for emeta ... Traceback (most recent call last): [snip] KeyError: 'app-portage/emeta-2.0.5' It does this because it knows it can't accurately report the masking status of an ebuild that's no longer on the system. For that reason, we need to introduce a new way to represent this situation. Something like: [I-O] [--] app-portage/emeta-2.0.5 (0) or [I-O] [??] app-portage/emeta-2.0.5 (0) or whatever. After it's coded in and documented, it probably shouldn't be changed. So I'm asking democratically, what should the symbol for "unknown mask status" be? Reproducible: Always
Let's go ahead and use ?? instead of the XX that is currently in use. I think question marks are a litte clearer.
(In reply to comment #1) > Let's go ahead and use ?? instead of the XX that is currently in use. I think > question marks are a litte clearer. > Sure, fixed in r146.
Released in gentoolkit-0.3.0_rc9
