On Wed, Sep 16, 2015 at 4:17 PM, Michał Górny <mgo...@gentoo.org> wrote: > > If you modify an eclass, you're responsible for the outcome. Even if > means revbumping hundreds of ebuilds for the sake of it. Note that this > is the kind of revbump that wouldn't require resetting stable keywords > as long as deps are satisfied.
Ok, so it sounds like there are two eclass proposals out there: 1. Modify the eclass in place and then revbump all ebuilds that use it for which the new RDEPEND matters (the second part of this email). 2. Don't modify the eclass in place, and then update the eclass reference and revbump any ebuilds for which the new RDEPEND matters, and for the ones that don't matter there really is no change since they use the old eclass. #1 results in less eclass propagation, but requires mass-commits. #2 seems safer and allows the eclass and ebuilds to be modified separately, but still requires lots of ebuild changing. > > Runtime. The minver can be raised for developer's convenience -- like > when a large number of packages is expected to require a new version > soon, and the developers would otherwise have to override the eclass- > specified versions. Instead, the eclass is updated and new requirements > apply. Does not revbumping in this situation actually save us much other than the need to do the revbumps themselves? If the dependency uses a slot operator then everything is going to get rebuilt anyway as soon as the first package comes along and triggers an update. Then again, it does save us a bunch of revbumps. -- Rich
