Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Wed, Sep 16, 2015 at 1:09 PM, Rich Freeman <rich0@g.o> wrote:
>
> I'll go ahead and start a tangent on this thread right here.  As a
> first step can we separately consider the proposal to require a
> revbump anytime a package's RDEPENDS changes?  I'm referring here to
> directly-specified RDEPENDS, not those inherited from an eclass or
> virtual.

Ok, for the purpose of the upcoming council meeting, I'd like to make
a few separate proposals around dynamic dependencies.
There are three categories of policies:
1.  RDEPEND changes directly in ebuilds.
2.  RDEPEND changes directly in virtuals.
3.  RDEPEND changes in eclasses.

Honestly, I'm not really convinced virtuals need special treatment,
but I split them off in case it is useful in discussion.

RDEPEND changes directly in ebuilds
Proposal 1: Anytime an RDEPEND in a non-virtual ebuild is changed, the
ebuild must be revisioned.  This includes adding/removing inherited
eclasses which set RDEPENDs.

RDEPEND changes directly in virtuals
Proposal 2: Anytime an RDEPEND in a virtual ebuild is changed, the
ebuild must be revisioned.  This includes adding/removing inherited
eclasses which set RDEPENDs.

RDEPEND changes in eclasses
Proposal 3: Anytime an RDEPEND in an eclass is changed, the eclass
must be revisioned.
Proposal 4: Anytime an RDEPEND in an eclass is changed, all ebuilds
that inherit the eclass in the gentoo repository must be revisioned.

Please speak up if you have any issues with any of these.

I'm leaning towards adopting 1, 2, and 4.  I would actually prefer 3
to 4 on principle, but we don't have a good way of retiring obsolete
eclasses and I don't want to see a huge multiplication in them.  If we
did adopt #3 we should probably start thinking about more consistent
version numbering for eclasses since I could see multiple active
series of eclass versions being updated in parallel.

I'll also note that the wording of Proposal 4 doesn't preclude doing
proposal 3 if the eclass maintainer thinks it is appropriate (maybe
the RDEPEND should only change in some circumstances or there are
other changes happening at the same time).  The wording of Proposal 4
refers to when an eclass is changed, and if you make the change in a
new revision you aren't changing the previous one, and so you don't
need to bump all the ebuilds.  Of course the ebuilds would still need
to be bumped if they were modified to use the new eclass, per proposal
1.

Proposal 3 is superior to proposal 4 from the standpoint of overlays
that use eclasses in the main repository, since nobody will be going
around and revbumping their ebuilds.  Of course, any eclass change
should be posted on -dev and so there would be notice.

Adopting 1, 2, and at least one of 3 or 4 would eliminate all the
dynamic dependency issues in the tree.  If anybody is aware of any
that I missed and I'll add them.

Also, in the event proposal 1 and 2 are both adopted, here is proposed
streamlined wording:
Proposal 5: Anytime an RDEPEND in an ebuild is changed, the ebuild
must be revisioned.  This includes adding/removing inherited eclasses
which set RDEPENDs.

However, the council doesn't have to approve the literal wording of
everything in the devmanual, so that might be overkill.  The devmanual
can of course explain the rationale for avoiding dynamic deps/etc.

-- 
Rich