-----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 <ri...@gentoo.org> > 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-----
