Summary: | repoman check for {R,}DEPEND set | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Peter Volkov (RETIRED) <pva> |
Component: | Repoman | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | InVCS |
Priority: | High | ||
Version: | 2.2 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 210077, 254662, 285191 | ||
Attachments: | detect case where DEPEND is set and RDEPEND is unset |
Description
Peter Volkov (RETIRED)
![]() RDEPEND is the only one that's set automatically, so shouldn't we only warn if there's no RDEPEND assignment? Also, I can imagine that some ebuilds have empty DEPEND and RDEPEND (like things that really only depend on libc). For such cases, should we allow a missing RDEPEND assignment if DEPEND is also missing? (In reply to comment #1) > RDEPEND is the only one that's set automatically, so shouldn't we only warn if > there's no RDEPEND assignment? > > Also, I can imagine that some ebuilds have empty DEPEND and RDEPEND (like > things that really only depend on libc). For such cases, should we allow a > missing RDEPEND assignment if DEPEND is also missing? First, emtpy != missing. We only care about missing here. If a packages really has no deps, it should state both DEPEND="" and RDEPEND="". As for the check, for now I suggest to only hceck for implicit RDEPEND assignments (RDEPEND is unset, DEPEND is non-emtpy) so it doesn't trigger for packages that get their deps completely from eclasses. If necessary it can later be adjusted to also check for unset DEPEND. Created attachment 178936 [details, diff]
detect case where DEPEND is set and RDEPEND is unset
Since it's only triggered when DEPEND is set, it avoids false positives in cases when all deps come from the eclass(es).
This is fixed in 2.1.6.7 and 2.2_rc23. |