Lot of ebuilds depend on stuff listed in profiles/base/packages. This is, as I've been told, a bad idea, and should be easy enough to check for algorithmically(sp?). A repoman warning would be nice. (I don't know python at all, so don't ask me to provide a patch. I am filing this in good hope that some day, someone finds his time for this and writes the code.) Thanks for your time.
> This is, as > I've been told, a bad idea, and should be easy enough to check for > algorithmically(sp?). A repoman warning would be nice. It's usually unneeded cruft, but it's not all that bad. Also, in some cases it is necessary, so the check would give false positives.
Only situation I can think of where it would be needed is when depending on a specific (minimum) version of such package - this can of course be ignored by repoman. Of course, I don't claim I'm a dep resolver guru, so if you claim that there are other situations where it's needed, I'll believe you.
I don't think this would be viable for several reasons: a) packages within "system" need to have explicit deps b) I don't like the idea of hardcoding "profiles/base" in repoman, and a new file in the tree would be just cruft IMO c) little to no actual benefit d) there are valid reasons to depend on "system" packages even in normal ebuilds e) I don't really like the assumption of "implicit system dependency" in general as there isn't such a thing, basically it's all based on the expectation that the user will regulary update the "system" target (but that's beyond the scope of this bug) f) profiles change over time, don't like the idea of devs excluding a dep because repoman said it was unneeded at some point So summary: little to no benefit, medium risk, unknown cost
