Re: [gentoo-dev] Dynamic dependencies

[Michał Górny]

Dnia 2015-09-16, o godz. 17:49:24
"Andreas K. Huettel" <dilfridge@g.o> napisał(a):

> Hi all,
>
> here's a quote from the Council 20140826 summary:
>
> > Dynamic dependencies in Portage
> > ===============================
> > During discussion, is was remarked that some changes, e.g. to
> > dependencies in eclasses, could require mass rebuilds of packages.
> >
> > Vote:
> > - "The council asks the Portage team to first outline their long-term
> >   plan regarding removal or replacement of dynamic dependencies,
> >   before they remove this feature. In particular, tree policies and
> >   the handling of eclasses and virtuals need to be clarified."
> >   Accepted unanimously.
>
> Since there seems to be interest in the Portage team to go ahead with that
> plan, I'd like to ask about the tree policies and the handling of eclasses and
> virtuals.
>
> I guess we'd appreciate this as a prerequisite for being able to give the plan
> future council support.

How about the usual 'common sense' policy? Assuming the developer
understands the consequences of bumping and not bumping, and can see
for himself if the latter breaks stuff (which would happen once portage
finally changes the default behavior and makes failures non-random).

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.

Long story short:

1. Build-time dependency changes don't need revbump unless they
resulted in broken built package. Pretty much like any other build-time
fix.

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.

3. For non-important fixes, a revbump is recommended. Like when
the package rarely breaks due to missing dep, or the dependency is
implicitly pulled in but should be listed explicitly for completeness.

4. For any change that could result in conflicts or major problems for
people who are stuck with old metadata, revbump is required. This for
example applies to the Perl team virtuals which frequently make
updating impossible.

There are probably more common cases to be considered but that's
the ones that immediately come to my mind.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>