On 27 July 2014 19:16, Martin Vaeth <mar...@mvath.de> wrote: > Not at all, it is completely identical to a revision bump: > If you would use -r2 instead of -r1.1, you also would end up > in -r1 and -r2 being identical. > Actually, in both cases, you would *remove* -r1, since -r1 is incorrect > since it should have been bumped. > > It just seems strange to me to go round a large tree and bump every ebuild affected by an eclass change, simply not modifiying the code, buy changing the -r value on the end of it.
In a "no dynamic deps, period" scenario, this just strikes me as 2 flavours of the same weirdness, -r2 and -r1.1 are just equally weird choices to make if the ebuild itself doesn't change at all. For some things it would be a nightmare of impossibility for even a trivial change if some eclass changed to have one new dependency/one less dependency. You'd need some system in place to go around the tree -r bumping things, and the system would involve humans who are prone to making mistakes, and create commit churn to make it happen. The same problem would still persist with people forgetting to -r bump, or missing one ebuild in the ~200 affected, but with dynamic deps off, those bugs would lie in wait and confuse portage until somebody filed a bug and it got responded to. Sure, having an approved system to ship dependency-only changes to the end users tree is something we do need, I'll grant that, but the point of failure is already significantly weighing on developer time, and this would see a growth in developer time to manage this ( I could be over estimating how much, but -r bumping everything that used a specific eclass is something I very much do not envy ). However, if there was a system in place such that developers didn't have to manually do any -r bumping , but "some system" acknowledge the changes and scheduled some kind of VDB update in response to some kind of data that was transmitted as part of the sync, that would be nice. -r bumping is of course *a* way to transmit the data. Just I feel strongly inclined that we shouldn't be making developers expend *more* effort to solve this problem if there's a way we can make them spend *less*. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
