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