Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Wed, Sep 16, 2015 at 3:31 PM, Michał Górny <mgorny@g.o> 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