On 10/01/2015 02:34 PM, Rich Freeman wrote:
>
> RDEPEND changes directly in ebuilds
> Proposal 1: Anytime an RDEPEND in a non-virtual ebuild is changed, the
> ebuild must be revisioned. This includes adding/removing inherited
> eclasses which set RDEPENDs.
>
This gets conflated with dynamic dependencies, but really, it's already
necessary. Not doing so hurts users of other package managers, and even
users who use portage with dynamic dependencies turned off. The PMS is
the gospel here, so we should be following it. Thou shalt revbump. Doing
so does not cause unnecessary rebuilds, because the rebuilds are already
necessary, so they're not unnecessary.
Obviously I'm a +1, and I think we should push this through even if
there's ongoing discussion about the other proposals. I have a patch for
the devmanual[0] that would clarify this (existing) policy. Here's what
I suggest:
Increment the revision number whenever you change an ebuild. New
revisions are subject to the keyword policy for upgrades. A few
exceptions to this rule are outlined below. If you are unsure,
increment the revision number. However, in the following cases, you
may modify an ebuild in-place:
WARNING: These exceptions do not apply to stable ebuilds. Only under
/exceptional/ circumstances should you modify a stable ebuild.
* Fixes for compilation failures. These do not affect users
who have already managed to build the package, so there's no
reason to force the package to be rebuilt.
* Changes to comments.
* Modification of build-time dependencies. Use this exception
sparingly; for example, when the package takes a long time to
compile.
Basically: revbump unless you happen to know better.
[0] https://560356.bugs.gentoo.org/attachment.cgi?id=411926
