Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/10/15 02:34 PM, Rich Freeman wrote:
> 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.
>

Seconded, with the exclusion of package renames, as those can be
handled in-place with 'pkgmove' VDB updates.

Slotmove VDB updates *should* be allow slotmove-related changes to
be excluded here too, but unfortunately with portage not doing
updates to rdeps properly, at this time all rdeps will need to be
revbumped when their RDEPEND changes.



> 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.


Seconded; virtuals are empty so its not a big deal here


>
> 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.

This one is trickier to deal with.  For starters, after thread
between yourself and mgorny and I, I think we figured out that there
wouldn't be an end-user breakage from people that have emerged a
package eclass-rdepend'ing on one depset, when that depset is
changed; it just ends up with everyone after the time of the change
needing the new depset.

There are specific cases where the revbump to rdeps will be
necessary (and the eclass itself too, *if* keeping the old eclass
around or differentiating which eclass version is inherited actually
matters):

- - slotmove operations on a dep in *DEPEND
- - the addition of blocker atoms due to the introduction of
conflicting packages
- - the addition of atoms to address implicit dependencies that were
missed before (and weren't in the ebuilds)
- - adjustments to atoms based on changes made to the dependent
package, with the changes now necessary to prevent breakage.  (IE:
useflags changed in-place on a dep and the packages inheriting the
eclass now need to ensure that the new useflag is set)

...there are likely other cases but I can't think of any right now.

At any rate, the point here being that a simple minimum-version-bump
in an eclass RDEPEND does indicate a divergence will occur between
end-user VDB and the repo, but that doesn't necessarily mean it's
something we need to avoid, or rather, we don't necessarily -need-
to enforce convergence between the repo and end-user VDB.


Once we get a bit more hashing out of the above I can try writing up
the complicated proposal(5?,6?) wording...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF0EAREIAAYFAlYNhJAACgkQAJxUfCtlWe2oXQD2ILHhFlsTJ8FYXbzSROA4hsnE
FGV17l9WmWr31NlrpQD+Iw5tbN/qzeDSZZXXv8/YbXu82IhgB5qK3FZjmxdEEkU=
=hYNh
-----END PGP SIGNATURE-----