On Fri, 18 Nov 2016 00:13:35 +1100 Michael Palimaka <kensing...@gentoo.org> wrote:
> What is the *real* risk that kde-apps/kcalc builds against stable > dev-libs/gmp but then starts producing funny numbers at runtime? > > Let's put it another way - assume we're stabilising a new version of > dev-libs/gmp instead. Should we test already-stable kde-apps/kcalc > first? What about the other hundred reverse dependencies? > > Just to be clear, I'm not advocating banning runtime testing. I just > think that, considering the state of the stable tree, we should consider > very careful in which situations we actually gain value from it. That's > for another thread, however. I deliberately worded the document so that > the final decision on the exact level of testing required (runtime or > otherwise) is between the person filing the stabilisation request and > the person actioning it. This IME rather depends on the nature of the package in question, and the general nature of its dependencies. Usually you can make the conjecture that only direct dependents of each other can affect each other via changes. But spooky-action-at-a-distance can also happen, where in a -> b -> c C changes B is unaffected A is broken Though it makes more sense to not have a blanket "recusively check dependents" policy, and perhaps either have a "Test these things when I change" list, or an inverse "Test me when X changes" list. The latter of these is not entirely unlike the need to add new := slotdeps for things that didn't need to depend on Perl, but needed to be rebuilt when perl is. (Except s/rebuilt/retest/ )
pgptXz8q8iYvw.pgp
Description: OpenPGP digital signature
