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

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

[Tomáš Chvátal]

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 
:]

Cheers

Tomas

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

[Zac Medico]

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

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

[Tomáš Chvátal]

Zac Medico wrote:
> 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.
> , 
That is another possibility but i tried to have something that is notdependant 
on IUSE.

Because when you have it depending on iuse you will have to alter the ebuild 
in future anyway, when the depending library will get OK.

It could be nice solution until we can launch support for the above file :]

Tom

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

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 1076 bytes --]

On Saturday 10 of October 2009 22:50:37 Zac Medico wrote:
> Maybe a syntax extension for IUSE would be a little nicer. For example:
> 
>   IUSE="unstable? ( foo bar )"

No no no, the biggest reason for this is to not touch ebuild at all - it needs 
to be fully ebuild independent.

It's like with recent KDE4 stabilization. Having ability to exclude certain 
optional dependencies from stabilization *without* modifying ebuilds (remove 
USE flag and its support from IUSE) is the motivation here.
For now - we just mask them in package.use.mask with appropriate version 
specification (let's say <=kde-base/kdeutils-meta-4.3.10 cups) - but it's not 
ideal as you may think.

It's no surprise, we don't manage ebuilds in *purely* individual manner - 
instead we try to keep all ebuilds across all releases the same if possible 
(eclass handles it properly) - it's over 250 of them after all and we maintain 
now 4.3.1, 4.3.2, 4.3.9999 (stable branch - what makes next 4.3.x releases), 
9999 (pure trunk) and trunk snapshots like 4.3.69.

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Joshua Saddler]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Sat, 10 Oct 2009 22:04:50 +0200
Tomáš Chvátal <scarabeus@gentoo.org> 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 

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?

* * *

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.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Tomáš Chvátal]

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

[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