Re: [gentoo-dev] Re: don't rely on dynamic deps

[Rich Freeman <rich0@gentoo.org>]

On Mon, Jul 28, 2014 at 2:27 PM, Ian Stakenvicius <axs@gentoo.org> 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