Summary: | Wants to add per package display of ~arch and M | ||
---|---|---|---|
Product: | Portage Development | Reporter: | jb <benoitj> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
jb
2005-09-26 14:13:10 UTC
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. |