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