On Thu, Oct 1, 2015 at 3:08 PM, Ian Stakenvicius <a...@gentoo.org> wrote: > >> >> 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...
Agreed. Thanks for bringing this up again. If you're adding an RDEP to an eclass in anticipation of it being necessary for new ebuilds but all the ebuilds in the tree still work with the old RDEP, then the bumping can be selective. Rather than trying to identify specific cases, why not identify the intent, and then we can build out the individual cases on the devmanual, and revise it over time as necessary. Proposal 3a might be: Anytime an RDEPEND in an eclass is changed, the eclass must be revisioned unless all ebuilds in the gentoo repository will continue to work correctly with the old RDEPEND. Proposal 4a might be: Anytime an RDEPEND in an eclass is changed, all ebuilds that inherit the eclass in the gentoo repository must be revisioned if they will not continue to work correctly with the old RDEPEND. There is no need to have the council approve revisions to the devmanual every time somebody points out a new case where this happens. The goal here is to just let everybody air their opinions, and set a general direction so that those implementing it don't get caught in the crossfire. It sounds like pkgmove should be added to all the proposals as an exception. -- Rich
