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

Tomáš Chvátal wrote:
> Hi,
> lately I spoted that quite few packages have optional parts bit unstable (KDE
> parts, boinc [i wont stable it until the cuda is, i wont do the work explained
> bellow ], kipi,...).
> I really don't like the shebang about doing -r1 and -r50 so we keep 2
> revisions where one is stableable and second is not.
> So how about having this nice file (topic), it quite self-explainable by the
> name.
> Also syntax would be same as for package.use.mask and same goes for placement

Maybe a syntax extension for IUSE would be a little nicer. For example:

IUSE="unstable? ( foo bar )"

You could emulate this sort of extension in current EAPIs by simply
adding IUSE="unstable" and then using that flag to conditionally
disable things in *DEPEND, SRC_URI, and ebuild shell code.
--
Thanks,
Zac

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

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