I've just restored 1.2.15-r4, and it's the second time it is being restored today. Please bother checking keywords before removing packages. Keywords for media-libs/libsdl: | | u | | a a a p s | n | | l m r h i m m p s p | u s | r | p d a m p a 6 i p c 3 a x | s l | e | h 6 r 6 p 6 8 p p 6 9 s r 8 | e o | p | a 4 m 4 a 4 k s c 4 0 h c 6 | d t | o -------------+-----------------------------+-----+------- 1.2.15-r4 | + + + o + + o ~ + + o ~ + + | o 0 | gentoo [I]1.2.15-r8 | ~ + + ~ + ~ o ~ + + o ~ ~ + | o | gentoo There's also a stablereq for remaining keywords open...
<Mr_Bones_> meh. fringe archs are fringe. there's already a stablereq bug for them so the breakage will settle down in a while. So what we have here is intentional, repeated tree breakage which additionally made it impossible to properly commit dependency updates due to app-eselect move and caused users a lot of pain. I would like to summon a QA vote for action.
Yaaaa, drama!
Well, as I read in bug 522270 looks like the stabilization was pending since September! and, then, I guess Mr. Bones was applying that policy of "maintainers being allowed to drop old versions after 90 days": https://archives.gentoo.org/gentoo-dev/message/4d803e54cfabb9756f9b7b64ef44c2c2 I have explained many times the reasons *I* think that policy is really not applicable due to issues like this one... but until know I guess we are blocked until some day we decide to move ia64/sparc/alpha to testing finally... but that is beyond my area :(
(In reply to Pacho Ramos from comment #3) know -> now... time to go to sleep :S
(In reply to Pacho Ramos from comment #3) > Well, as I read in bug 522270 looks like the stabilization was pending since > September! and, then, I guess Mr. Bones was applying that policy of > "maintainers being allowed to drop old versions after 90 days": ... which would be ok if all reverse dependencies were de-keyworded with it. Breaking the dependency graph of visible (i.e. not masked, having any keywords) ebuilds is not cool, and repeated breakage even less.
Can we get the council to clarify that knowingly breaking the stable depgraph is not acceptable in that case?
(In reply to Mike Gilbert from comment #6) > Can we get the council to clarify that knowingly breaking the stable > depgraph is not acceptable in that case? I believe the last official vote on this topic is recorded here: https://wwwold.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt At that time, this action would be permitted for alpha and ia64, but not for sparc. So, this particular removal was not permitted, but would be permitted if the newer version was stable on sparc, and had no known flaws on ia64 and alpha IF UPSTREAM SUPPORTS THEM (if upstream does not, then they could be removed even with flaws at the maintainer's discretion - an ia64/sparc user could of course choose to step in to maintain the old version, but then they get to do the work). I believe it was fully appreciated that this policy would result in broken stable depgraphs on those archs. It was a compromise because the arch teams did not want to drop stable entirely, but ultimately it is on them to deal with the carnage if they don't keep up. It isn't fair to maintainers to have to keep old versions around forever if arch teams can't keep up with STABLEREQs, so this policy basically forces everybody to have skin in the game, while still giving most of the benefits of a stable arch. If somebody wants the council to revisit the policy (contracting or expanding it), by all means request this for the next agenda. I'm posting this on my own behalf only, and just as my understanding of what the past council decision was. The council can choose to further comment after the next meeting.
Looks like indeed a tree breakage for alpha and ia64 was "expected" as I saw yesterday when looking for other news item :/ https://www.gentoo.org/support/news-items/2013-10-24-minor-arches-2.html
The council has looked at this and it doesn't seem like there's any action for us to take at this time.
