Re: [gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches & news item for review)

[Brian Harring <ferringb@gmail.com>]

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

On Sun, Mar 14, 2010 at 02:02:46AM +0200, Mart Raudsepp wrote:
> On Sat, 2010-03-13 at 13:16 -0800, Brian Harring wrote:
> > While I agree in principle within mixins, no one here is discussing 
> > the QA affect of it- right now we can do visibility scans of 
> > combinations of gnome + amd64 + 2010 because they're defined.
> 
> What sort of QA affects do you imagine it having?

Simple enough.  Right now, you change a profile, or want to stable a 
pkg, you can do a scan and identify all new visibility issues from 
profiles- you can validate up front that for the list of 
supported/stable profiles, these changes occur.

If things are shifted over to prefering users mixing/matching profiles 
on their own (meaning we no longer have a gnome amd64 2010 for 
example), devs no longer get QA warnings when they break stuff for it.

Users see it however.

> Though I'm talking in the context of what I proposed - using it for just
> the target profiles that only tweak USE flags and other such defaults,
> nothing else.

Current QA (repoman/pcheck), if a use flag is defaulted on, it's deps 
in a pkg must be visible.  Via repoman/pcheck, they ensure that the 
default use configuration for a profile, all visible pkgs dependencies 
are visible (making the pkg fully usable).

Consider mixing/matching gnome/kde with a profile that has quite a few 
packages masked- say mips.  To be clear, this is a hypothetical case- 
I know it exists, I'm just choosing two likely targets.  Say gnome 
requires some codecs use flag flipped on triggering a dep on a pkg 
masked for mips.

I'm not saying these situations can't be worked around- we already fix 
them now as they come up.  The thing is, whenever you change something 
now, those profile combinations are validated- with mix/match 
approach, that validation won't be occuring, the users will be the 
ones seeing the breakage rather than the dev.

> I considered QA affects for that case, at least in my own
> thoughts. I think QA would be checked anyhow there, as part of all USE
> flags enabled assumpting testing or static testing of various USE flag
> combinations of a package (e.g, for statically finding circular
> dependencies or the like).

Either you're suggesting that repoman/pcheck would have to scan all 
arbitrary combinations of gnome/kde/desktop w/ misc arches, or you 
need to be a fair bit more precise about how QA tools would identify 
what profile combinations to check.

If you're proposing that the QA tool arbitrarily combines arches w/ 
various desktop/server mixins, I'll again note that the run time of 
visibility scans is directly related to # of profiles to check- for 
example, removal of mips profiles from profiles.desc is if memory 
serves me a ~33% reduction in visibility runtime for pcheck.

For repoman (which all devs have to use for commiting), # of profiles 
is even more of a critical value performance wise.


> Do you foresee bad QA affects for the for the
> desktop/developer/gnome/kde/server profiles case too, or just when
> mixing in selinux/toolchains/etc?

Issues will exist regardless of what the combination is.  The point 
I'm making is that with the current model, we catch those issues prior 
to commit- having users mix/match on their own means users will see 
those issues rather than devs.  Literally, they'll see the breakage.

~harring

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