| 1 |
On Mon, Jul 28, 2014 at 2:27 PM, Ian Stakenvicius <axs@g.o> wrote: |
| 2 |
> |
| 3 |
> The primary underlying problem I see about this is that it doesn't |
| 4 |
> force devs to start doing something to the tree that will suddenly |
| 5 |
> help make all of the static-deps-only PMs (ie, those that aren't going |
| 6 |
> to implement this new hash-changed-so-re-evaluate-ebuild method) |
| 7 |
> suddenly work in a more consistent fashion. IIRC, the very first post |
| 8 |
> of this thread was a reminder to dev's to revbump so that static-deps |
| 9 |
> behaviour is more correct/consistent. |
| 10 |
|
| 11 |
I think the intent here is to define how we want the PM to behave, and |
| 12 |
what kinds of changes should require revbumps (ie those the PM can't |
| 13 |
handle otherwise). |
| 14 |
|
| 15 |
Obvious a side-effect of this will be that PMs that don't behave as we |
| 16 |
intend them to may have issues. |
| 17 |
|
| 18 |
> |
| 19 |
> However, if we put something into the next EAPI about this and make it |
| 20 |
> a requirement for all PMs (although I have no idea how we would roll |
| 21 |
> this out; maybe make it a profile-level requirement instead of an |
| 22 |
> ebuild-level one, if there is such a thing??) |
| 23 |
|
| 24 |
It may make sense to do this via a new EAPI, though I think figuring |
| 25 |
out what we want to do comes first. That is, I want to ask the |
| 26 |
question "if no PMs existed and we were writing our first one, how |
| 27 |
would we want it to behave?" Getting from here to there is the next |
| 28 |
problem. |
| 29 |
|
| 30 |
Really the issue comes down to how we maintain ebuilds. If we aren't |
| 31 |
revbumping for dependency errors, then PMs that don't handle dynamic |
| 32 |
deps wouldn't update their dependencies. That certainly has |
| 33 |
consequences, but whether they're considered "bugs/problems/etc" is a |
| 34 |
bit up for debate. |
| 35 |
|
| 36 |
I'm not convinced that it makes sense to do "micro-revbumps" just to |
| 37 |
force PMs that don't have any concept of dynamic dependencies to treat |
| 38 |
them as full revbumps. Devs can still forget to do them, and it |
| 39 |
results in churn that doesn't seem necessary to me. On the other hand |
| 40 |
I don't want to make life even more difficult on those using |
| 41 |
alternative PMs (though it sounds like we're doing this already). |
| 42 |
|
| 43 |
It seems like we aren't getting many more new options here. |
| 44 |
|
| 45 |
Rich |
Archives