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