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