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 |