when emerging with the -v option, it display a notice for package in overloay, as [ebuild N ] sys-apps/genpass-0.2 10 kB [1] Portage overlays: [1] /usr/local/portage Is it possible to display the ~arch and the fact that the package is masked in a similar way, per exemple like that : [ebuild N ] sys-apps/genpass-0.2 10 kB [1] [~86] [M] Because of the per ebuild keyword, it can be of a great help. thanks Reproducible: Always Steps to Reproduce: 1. 2. 3.
Current behavior is for emerge -pv <masked/~arch/not keyworded package> is for emerge to display to you that it is not keyworded/masked. For example: emerge -pv mol These are the packages that I would merge, in order: Calculating dependencies !!! All ebuilds that could satisfy "mol" have been masked. !!! One of the following masked packages is required to complete your request: - app-emulation/mol-0.9.71_pre1-r2 (masked by: -* keyword) - app-emulation/mol-0.9.71_pre1 (masked by: -* keyword) - app-emulation/mol-0.9.71_pre1-r1 (masked by: -* keyword) - app-emulation/mol-0.9.70 (masked by: -* keyword) - app-emulation/mol-0.9.70-r1 (masked by: -* keyword) For more information, see MASKED PACKAGES section in the emerge man page or section 2.2 "Software Availability" in the Gentoo Handbook. You want this changed to read: [ebuild N ] app-emulation/mol-0.9.71_pre1-r2 0kB [-*] Personally I dislike it because it doesn't immediately tell you that something is wrong, ie that mol is not keyworded.
My understanding was that the request is for packages that are unmasked. If it's for packages that are masked, then no way...
Sorry, I was not clear enough. In make.conf, i have commented ~x86. In /etc/portage/package.keyword, there is a line like : sys-apps/genpass-0.2 ~x86 Has I have commented the ~x86 in make.conf, It's not easy to see if genpass will be emerge in the stable way or in the instable way, because I have to parse the full package.keyword file to find that. Therefore, I want emerge to display the fact that the package i'm going to emerge will be a ~arch version.
I'd rather not do this for the following reasons: - it requires some IMO nasty internal tricks - it gets quite complicated as soon as you think outside of the normal arch->~samearch update - it doesn't deal nice with temoporary env changes - is it only for arch->~arch updates? or also for ~arch->~arch updates? what about ~arch->arch or p.mask->~arch? In short: too many possible combinations (one of the drawbacks of the masking system). Unless someone fundamentally disagrees with me I'd consider this WONTFIX.
closing as per previous comment.