| 1 |
On Sat, 10 Oct 2009 22:04:50 +0200 |
| 2 |
Tomáš Chvátal <scarabeus@g.o> wrote: |
| 3 |
|
| 4 |
> Hi, |
| 5 |
> lately I spoted that quite few packages have optional parts bit unstable (KDE |
| 6 |
> parts, boinc [i wont stable it until the cuda is, i wont do the work |
| 7 |
> explained bellow :)], kipi,...). |
| 8 |
> I really don't like the shebang about doing -r1 and -r50 so we keep 2 |
| 9 |
> revisions where one is stableable and second is not. |
| 10 |
> So how about having this nice file (topic), it quite self-explainable by the |
| 11 |
> name. |
| 12 |
> Also syntax would be same as for package.use.mask and same goes for placement |
| 13 |
|
| 14 |
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: |
| 15 |
|
| 16 |
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. |
| 17 |
|
| 18 |
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. |
| 19 |
|
| 20 |
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? |
| 21 |
|
| 22 |
* * * |
| 23 |
|
| 24 |
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. |
Archives