| 1 |
Michał Górny schrieb: |
| 2 |
>> You are changing the API of versionator.eclass, even if it was unintentional API. |
| 3 |
> |
| 4 |
> There is no such thing as 'unintentional API'. API is what's described. |
| 5 |
> If you rely on internals, random undefined behaviors or whatever, it's |
| 6 |
> not a part of the API. |
| 7 |
|
| 8 |
Well there is the API according to the docs, and then there is the API |
| 9 |
according to the implementation... |
| 10 |
|
| 11 |
>>> Then ebuilds will fail just the same |
| 12 |
>> |
| 13 |
>> No. Before, ebuilds would maybe display an upgrading message when they |
| 14 |
>> shouldn't, or vice versa. Now the eclass dies on them. |
| 15 |
> |
| 16 |
> So what's the alternative? Design another eclass where ebuilds will |
| 17 |
> fail just the same because people will ignore the more explicit |
| 18 |
> requirement just the same as they do ignore the API? |
| 19 |
|
| 20 |
I don't know what is your problem here. The eclass needs not be designed |
| 21 |
again from the ground up. |
| 22 |
All ebuilds which are unaffected by bug 589444 can be switched to the new |
| 23 |
eclass/functions immediately. The others after they are changed no longer |
| 24 |
make the implicit assumption that REPLACING_VERSIONS contains only a single |
| 25 |
version. |
| 26 |
|
| 27 |
> The problem is not 'there is a valid case to pass useless parameters |
| 28 |
> to the function'. The problem is 'I make an invalid assumption about |
| 29 |
> what will happen based on my limited knowledge which I believe is |
| 30 |
> more correct than people who wrote package managers'. |
| 31 |
|
| 32 |
I don't say it is a correct use of versionator.eclass. I just say it has |
| 33 |
become (unintentionally) part of the API, and therefore is subject to the |
| 34 |
rules about changing APIs in eclasses. I agree that relying on unintentional |
| 35 |
or undocumented API is bad and needs to be addressed. |
| 36 |
|
| 37 |
|
| 38 |
Best regards, |
| 39 |
Chí-Thanh Christopher Nguyễn |
Archives