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