Dnia 2015-09-16, o godz. 17:49:24 "Andreas K. Huettel" <dilfri...@gentoo.org> napisał(a):
> Hi all, > > here's a quote from the Council 20140826 summary: > > > Dynamic dependencies in Portage > > =============================== > > During discussion, is was remarked that some changes, e.g. to > > dependencies in eclasses, could require mass rebuilds of packages. > > > > Vote: > > - "The council asks the Portage team to first outline their long-term > > plan regarding removal or replacement of dynamic dependencies, > > before they remove this feature. In particular, tree policies and > > the handling of eclasses and virtuals need to be clarified." > > Accepted unanimously. > > Since there seems to be interest in the Portage team to go ahead with that > plan, I'd like to ask about the tree policies and the handling of eclasses > and > virtuals. > > I guess we'd appreciate this as a prerequisite for being able to give the > plan > future council support. How about the usual 'common sense' policy? Assuming the developer understands the consequences of bumping and not bumping, and can see for himself if the latter breaks stuff (which would happen once portage finally changes the default behavior and makes failures non-random). As for virtuals and eclasses, I don't really understand why anyone thinks they are special in any regard. In both cases, we're talking about regular dependency change in metadata, and we need to understand the consequences. And they're going to be the same whether we change dep A to B, A to virtual, and whether we change it directly or via eclass. Long story short: 1. Build-time dependency changes don't need revbump unless they resulted in broken built package. Pretty much like any other build-time fix. 2. Dependency changes that don't need to apply immediately don't need revbump. For example, if foo.eclass raises minimal required version of a dependency but all packages built so far will work with the old one. 3. For non-important fixes, a revbump is recommended. Like when the package rarely breaks due to missing dep, or the dependency is implicitly pulled in but should be listed explicitly for completeness. 4. For any change that could result in conflicts or major problems for people who are stuck with old metadata, revbump is required. This for example applies to the Perl team virtuals which frequently make updating impossible. There are probably more common cases to be considered but that's the ones that immediately come to my mind. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgpS3cRu6UlKm.pgp
Description: OpenPGP digital signature
