1 |
On Sat, 2010-03-13 at 13:16 -0800, Brian Harring wrote: |
2 |
> On Mon, Mar 08, 2010 at 11:40:00PM +0100, Peter Hjalmarsson wrote: |
3 |
> > mån 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp: |
4 |
> > |
5 |
> > > Instead I think we should be improving "eselect profile" to support |
6 |
> > > multiple inheriting /etc/make.profile files in a user friendly fashion, |
7 |
> > > and in the end removing 249 subprofiles, instead of adding 28+. |
8 |
> > > |
9 |
> > |
10 |
> > |
11 |
> > I vote for this one. A profile being a only contains what is interesting |
12 |
> > for that profile, and you can "stash together" some profiles into your |
13 |
> > own cocktail. |
14 |
> > Yeah, I know it sounds horrible, but it would still be better then to |
15 |
> > only be able to focus on one small set. |
16 |
> > |
17 |
> > For example if I am using the GNOME DE, and have someone other also |
18 |
> > using my computer, but who really wants to use KDE. Should I have to |
19 |
> > find out what from the KDE profile to enable in my env to make my |
20 |
> > GNOME-profile also tingle for KDE? |
21 |
> > |
22 |
> > I think having a set of "base profiles" for toolchains and alike (i.e. |
23 |
> > default, hardened) would be good. Then be able to add for example |
24 |
> > desktop/gnome or server and/or selinux profiles on top would be |
25 |
> > interesting. This also for maintainers, as for example PeBenito can |
26 |
> > focus on the selinux part of the profiles, and do not have to keep up to |
27 |
> > date with which hardened-compilers are currently masked/unmasked. |
28 |
> |
29 |
> While I agree in principle within mixins, no one here is discussing |
30 |
> the QA affect of it- right now we can do visibility scans of |
31 |
> combinations of gnome + amd64 + 2010 because they're defined. |
32 |
|
33 |
What sort of QA affects do you imagine it having? |
34 |
Though I'm talking in the context of what I proposed - using it for just |
35 |
the target profiles that only tweak USE flags and other such defaults, |
36 |
nothing else. I considered QA affects for that case, at least in my own |
37 |
thoughts. I think QA would be checked anyhow there, as part of all USE |
38 |
flags enabled assumpting testing or static testing of various USE flag |
39 |
combinations of a package (e.g, for statically finding circular |
40 |
dependencies or the like). |
41 |
|
42 |
If you put selinux and toolchains in the mix, that indeed could be |
43 |
problematic to QA. Though one could probably define some profiles |
44 |
somewhere that would get used for QA testing, but not exposed to users. |
45 |
|
46 |
Do you foresee bad QA affects for the for the |
47 |
desktop/developer/gnome/kde/server profiles case too, or just when |
48 |
mixing in selinux/toolchains/etc? |
49 |
|
50 |
> If there is a shift to having users do the combinations themselves |
51 |
> (rather then combining w/in tree), there won't be visibility scans for |
52 |
> it- end result, more broken deps should be able to slide by, more |
53 |
> horked cycles, etc. |
54 |
> |
55 |
> A solution there would be useful- one that preferably doesn't involve |
56 |
> scanning every possible permutation of mixable profiles (you would |
57 |
> *not* like the speed affect that would have on repoman). |
58 |
> ~harring |
59 |
|
60 |
-- |
61 |
Mart Raudsepp |
62 |
Gentoo Developer |
63 |
Mail: leio@g.o |
64 |
Weblog: http://blogs.gentoo.org/leio |