On Wed, Sep 16, 2015 at 3:31 PM, Michał Górny <mgo...@gentoo.org> wrote: > > As for virtuals and eclasses, I don't really understand why anyone > thinks they are special in any regard. In both cases, we're talking > about regular dependency change in metadata, and we need to understand > the consequences. And they're going to be the same whether we change > dep A to B, A to virtual, and whether we change it directly or via > eclass.
Sure, but a developer KNOWS when their RDEPENDS change when they're modifying it directly in an ebuild. If they inherit an eclass and it sets an RDEPEND and the eclass changes, then it effectively changes the dependency for every ebuild that inherits it even though there weren't any commits to any of those ebuilds. So, we need to think about what kinds of changes we allow to eclasses. This also applies to virtuals, but those don't have the same kind of indirect impact to packages that RDEPEND on them any more than changes in any other RDEPEND of an RDEPEND. > 2. Dependency changes that don't need to apply immediately don't need > revbump. For example, if foo.eclass raises minimal required version of > a dependency but all packages built so far will work with the old one. > Are we talking about a build dependency or a run-time dependency? I don't get why we'd increase the minimal required version of a run-time dependency if everything built so far still works with the old version. Also, assuming that there is a case where this actually happens, does this have any impact on running --depclean or any other obscure blocker issues because the version in VDB is no longer in the tree? When the policy is just a simple "always revbump when you change RDEPEND, whether you're an ebuild, an eclass, or a virtual" then I can see how it is painful, but I can also see how it is fairly bulletproof. -- Rich
