| Summary: | app-portage/repoman: It should check relation between the latest non-live and a live ebuild | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Sebastian Pipping <sping> |
| Component: | Repoman | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Sebastian Pipping
2010-02-28 02:05:14 UTC
You want it to analyze the diff between two ebuilds? What kinds of things is it supposed to warn about finding in the diff? It should have to check for some very specific things or else it would just generate useless noise. There "must" be some way to prevent what I've seen happening with mplayer... not sure yet. So to turn this into a more constructive request: what I have in mind is the following: If there are both live and non-live ebuilds and both are of hybrid nature (e.g. containing several lines defining KEYWORDS) these files are expected to differ in CVS lines only. If they differ more, a warning (and maybe also a diff) is printed. So that should be both useful and doable. I can think of many changes that could occur if the 9999 is being kept up to date and the latest release is undergoing keywording/stabilization, etc... So, the code could evolve greatly in the 9999. It could even involve removing keywords in the 9999 (non 9999) keywords line in preparation for an upcoming release which adds new dependencies. The *DEPENDS could also be different. I think at most this could only be a warning, not a fatal error. I have been neglectful of a few 9999 pkgs myself, but I wonder if the coding effort involved to try and minimize the noise factor would outweigh the potential benefit. Seems like everyone agrees that it's not worth the effort. I'll close as good-enough/wontfix for now but please feel free to re-open if needed. |