Joshua Saddler wrote: > Don't take this too harshly, but doing it this way seems entirely > bass-ackwards to me. Why not just do one of the following: > > 1. Stabilize the dependencies. Make 'em all the same level. I went through > this the other from the other side when trying to get RedNotebook > stabilized: I couldn't do so until pyyaml, one of its dependencies, had > libyaml stabilized, since libyaml is an optional USE dependency for > pyyaml. Its not allways possible, testing users want the feature, but you cant trust that it is stable enought for stable enviroment. Namely the cuda feature in boic, Or the need for security update for openoffice, there was kde4 support removed because they could not wait for kde4 being stable. > > By forcing all three packages to be stable, *we prevented breakage to > users' systems from the beginning.* No need to mess with complicated > stable/unstable dependency relationships. > > 2. Don't mark the origin package stable in the first place! If its > dependencies aren't stable, then you cannot in good conscience declare > that the original package should be stable, and then "let the dependencies > sort themselves out" . . . weeks or months down the line. Just let it > *and* its deps remain in ~arch. What's so wrong with that? Also usualy users want the package, and if it is relatively stable current workflow is what i wrote above, 2 ebuilds with different revisions where one has the feature disabled and goes stable, so what is the difference against the p.u.s.m instead of more ebuilds. > > * * * > > Again, I really think it's bad QA and bad practice to mismatch stable > packages with unstable dependencies. Please tell us why 1. and 2. don't > work for you. > , Its not mismatchning, its like package.use.mask. You can say its not good for QA since you are depending on masked.package (usual usage) thus your package should not be in testing in first place since all deps are not in testing.
Cheers Tomas
