On Wed, Sep 16, 2015 at 4:44 PM, Ian Stakenvicius <a...@gentoo.org> wrote: > > - - emerge -uD @world would update the dep anyhow > > - - emerge -u @world wouldn't rebuild the package if that package > didn't change, and if the package did change then the new dep would > get built.
Just to be clear, my point was that if the reason the eclass was updated was because some new package version in the tree needed it, and you update that other package in the tree, then that will update the dependency, and that would in turn rebuild anything with a slot operator dep on it. Which is of course exactly what should happen if the soname/ABI needs to change. > > So I think I can safely drop my concern. Care still needs to be > given, certainly, as if the in-tree package isn't revbumped and gets > a patch that only supports the new dep, then suddenly systems will > fail when said package re-emerges. But that seems bad practice anyhow > . Right, a patch change would always require a revbump and that is nothing new. The only case that doesn't require a revbump is a build-time change. And if somebody makes a build-time change with the assumption that the new minimum depencency version is in effect it is fine, since anybody with it already installed won't be rebuilding it, and if anybody does rebuild it then portage will check and force the dependency update so everything is fine at build time. So, assuming we want to entertain the "only revbump if necessary" eclass wording, do we think we can actually come up with something that not only makes technical sense, but where we can actually expect developers to get it right 99% of the time? Are we encouraging dangerous behavior just because a few of us might or might not be able to get it right? I suppose if somebody does mess up we can go in and revbump a bunch of ebuilds. The thing is that such problems are very hard to detect - they usually manifest as users posting bizarre portage output on lists and forums and being showered with a lot of bad advice before somebody who knows what they're talking about notices the thread, and it can happen a while after the commit that introduced the problem. So, part of me really wonders if it is worth it just to save a bunch of revbumps that probably could be done by a script and with git it can even happen atomically and with the possibility of review or testing. -- Rich
