Summary: | repoman shouldn't report on files that are masked in package.mask | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Mr. Bones. (RETIRED) <mr_bones_> |
Component: | Repoman | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | Keywords: | InVCS |
Priority: | High | ||
Version: | 2.0 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 136244, 137445 |
Description
Mr. Bones. (RETIRED)
2005-03-16 18:44:13 UTC
Fixed on or before 2.0.51.22-r1 Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened. B0rken again in 2.1 dev-libs/luabind is masked, yet repoman full in that directory reports the broken deps (that are the reason the package is masked in the first place). (In reply to comment #3) > dev-libs/luabind is masked, yet repoman full in that directory reports the > broken deps (that are the reason the package is masked in the first place). There's some code in repoman that forces the --include-masked option when repoman is run in a package directory (level 3): if repolevel == 3 and "--include-masked" not in myoptions: myoptions.append("--include-masked") I'm not sure about the reason for this logic. The same code exists in 2.0.54 though, so apparently it's not a regression in 2.1. The main reason for not reporting on masked package issues was due to the amount of noise at category and tree levels. I don't mind having the package-level logic removed but I'd suggest a short option for --include-masked or repoman'ing masked packages will become a huge PITA. How useful is it to have something in the tree if it's dependencies can't be satisified? From my perspective, it should be punted immediately. I'd say that the safest route would be to invert the existing option and have a --ignore-masked feature instead. That will reduce the likelyhood that QA issues in a masked package will go accidentally unnoticed. Meaning invert the logic _and_ pull the per-package check, right? Yeah, I'd be happy with that too. There are only a handful of people that do category or tree checks so there shouldn't be much of an issue. The --include-masked option has been replaced with a --ignore-masked option (-i for short) in svn r3496. Sounds good to me. This has been released in 2.1.1_pre1. |