Joshua Saddler posted on Sat, 10 Oct 2009 23:55:51 -0700 as excerpted: > 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. > > 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?
While these may well work for individual packages, consider a "suite" such as X or one of the desktop environments. I'll use KDE since I /do/ use it. I have nowhere near the whole kde installed and it's 172 packages, IIRC, so there's gotta be 250 or so, more I think (it says 94 new ones and one in a new slot if I merge kde-meta, plus the 172, but some of those will be dependencies), in the entire DE-core. Are you /seriously/ proposing holding up all 250+ packages hostage just so one of the obscure bits can have an equally obscure optional dependency stabilized? Or are you proposing to kill support for that optional dependency entirely, when users might want that feature and have no problem package.keywording that single package to get it? I'd call both those solutions not entirely realistic. I'm just a user, but I know I've been unhappy with some of the dependency choices kde upstream has made. (More than once, I've asked myself, "What were they /thinking/!) Given the pattern we've seen, that sort of choice /will/ be forced on us, and while I'm not entirely happy about a new stable-use-masking file, it does seem a better alternative than we have now, either of your choices, or the split stable/~arch revision thing. Of course stable-only issues don't directly affect me personally, since I run ~arch and often development overlays and hard-unmasked packages anyway, but certainly, time spent worrying about stable isn't available to spend on more current packages, so if the stabilization process can be made more efficient and less troublesome, I'm all for it! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
