Strict compliance with the handbook would seem to forbid having a stable package depend on an unstable package, and if you have to downgrade a dependency and it causes a cascade, I would opine, that, perhaps, the package in question should not have been stabilized to begin with.
That said, I as a user have noticed that packages tend to stall in stabilization for awhile. What about a script that can rank ~arch keyworded packages by some sort of priority? Maybe point out which one has the most reverse dependencies? Or which one has been stuck in ~arch the longest? Or some sort of scoring mechanism that can flag the most urgently needed stabilizations? Come to think of it, I think debian has a system that flags the most popular packages. Does gentoo have a way to note what packages are most important? On Wed, Aug 17, 2016 at 1:50 AM, Pacho Ramos <pa...@gentoo.org> wrote: > El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió: > > [...] > > Well, I wasn't suggesting that breaking the depgraph is great. Just > > that I think it is better than calling things stable which aren't. > > > > A better approach is a script that does the keyword cleanup. > > > > So, if you want to reap an ebuild you run "destabilize > > foo-1.2.ebuild". It searches the tree for all reverse deps and > > removes stable keywords from those. Then you commit all of that in > > one commit. > > > > If you want to be extra nice you stick it in a pull request in github > > and point it out to the arch team and ask them if they're sure they > > don't want to stabilize your package... :) > > > > Well, the reason I was suggesting to allow maintainers to stabilize > after the 90 days timeout over *current* policy of allowing the > dekeywording is that the dekeywording is completely unrealistic to do > as some packages have a huge amount of reverse deps. Even with the > script (and, well, I would like to see that script existing... because > we are having this issue for ages, and that is the reason that nobody > is moving things to testing actively), you will find many many cases of > packages having so many reverse dependencies that if you try to move it > to testing it becomes soon a hell. > > The main issue is that, once you start dekeywording one package, you > jump to, for example, dekeywording another 3 reverse deps, then you > need to continue with the reverse deps of that reverse deps... and at > the end, it's completely impossible to manage it (I still remember how > hard was to move to testing most of Gnome... and we even were lucky as > we were able to do that with the jump to Gnome3). > > Then, my point it to allow the maintainer to keep stabilizing it > *after* the 90 days timeout. If after that time, the arch team is > unable to even reply, nobody has reported any build/runtime issues > related with that arch, I would go ahead. Otherwise, it looks pretty > evident to me that that arch is near to be used by nobody and maybe it > should be moved completely to testing (or most of their packages moved > to testing and only the core apps in stable). > > > >
