[gentoo-dev] Re: RFC: package.use.stable.mask

[Duncan]

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