| Summary: | glsa-check is confused by affected SLOT-ed packages | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Thierry Carrez (RETIRED) <koon> |
| Component: | Tools | Assignee: | Portage Tools Team <tools-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | sascha-gentoo-bugzilla, security |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Suppose a package is SLOTed and the following versions are installed : foo/bar-1.1.2-r3 (1) foo/bar-2.0.3 (2) A GLSA is issued with Affected: <2.0.3 Unaffected: >=2.0.3 Then glsa-check will say: Checking GLSA XXX-YYY The following updates will be performed for this GLSA: foo/bar-2.0.3 (2.0.3) This is (1) confusing, because the two versions are the same (2) inexact, because 2.0.3 is unaffected, and (3) inefficient, since applying GLSA instructions won't solve the problem. I think glsa-check should detect these corner cases and explain them better. We've had a few bugs about those already (every time we issue a GLSA on a SLOTted thing).