Patrick Lauer: > >>>> That means either say "you cannot expect anything, because there might >>>> or might not be metadata" or say "you can expect metadata for any >>>> provided/installed package" in which case package.provided feature has >>>> to be removed from portage. >>> >>> "Provided" means "not managed by the package manager" and thus returning >>> "empty metadata" for queries is perfectly fine. >>> >>> I don't see why this feature would need to be removed ... >> >> You just rephrased "you cannot expect anything, because there might or >> might not be metadata". > > So you're saying that if I remove metadata it is removed. > > Our tautology circle is true! Thanks for contributing these awesome insights. >
I'm saying that you didn't make an actual argument why it is better to allow non-existing metadata for installed packages and have every API user handle this exception. This will go horribly wrong if we start designing an API around portage hacks, assuming that the VDB might just be broken, inconsistent or "maybe valid". Is this about a portage API or a generic PM API? If it's about the former, then I'd rather see eix and friends broken for other PMs instead of spreading portage hacks over them (FYI: paludis has the "provided" case implemented without breaking VDB).
