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