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

[Mart Raudsepp <leio@gentoo.org>]

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

On Sat, 2010-03-13 at 13:16 -0800, Brian Harring wrote:
> On Mon, Mar 08, 2010 at 11:40:00PM +0100, Peter Hjalmarsson wrote:
> > mån 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp:
> > 
> > > Instead I think we should be improving "eselect profile" to support
> > > multiple inheriting /etc/make.profile files in a user friendly fashion,
> > > and in the end removing 249 subprofiles, instead of adding 28+.
> > > 
> > 
> > 
> > I vote for this one. A profile being a only contains what is interesting
> > for that profile, and you can "stash together" some profiles into your
> > own cocktail.
> > Yeah, I know it sounds horrible, but it would still be better then to
> > only be able to focus on one small set.
> > 
> > For example if I am using the GNOME DE, and have someone other also
> > using my computer, but who really wants to use KDE. Should I have to
> > find out what from the KDE profile to enable in my env to make my
> > GNOME-profile also tingle for KDE?
> > 
> > I think having a set of "base profiles" for toolchains and alike (i.e.
> > default, hardened) would be good. Then be able to add for example
> > desktop/gnome or server and/or selinux profiles on top would be
> > interesting. This also for maintainers, as for example PeBenito can
> > focus on the selinux part of the profiles, and do not have to keep up to
> > date with which hardened-compilers are currently masked/unmasked.
> 
> 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?
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. 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).

If you put selinux and toolchains in the mix, that indeed could be
problematic to QA. Though one could probably define some profiles
somewhere that would get used for QA testing, but not exposed to users.

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?

> If there is a shift to having users do the combinations themselves 
> (rather then combining w/in tree), there won't be visibility scans for 
> it- end result, more broken deps should be able to slide by, more 
> horked cycles, etc.
> 
> A solution there would be useful- one that preferably doesn't involve 
> scanning every possible permutation of mixable profiles (you would 
> *not* like the speed affect that would have on repoman).
> ~harring

-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://blogs.gentoo.org/leio

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