1 |
Brian Harring wrote: |
2 |
|
3 |
>On Mon, Aug 29, 2005 at 05:43:35PM -0400, Chris Gianelloni wrote: |
4 |
><snip> |
5 |
>Re: not shoving work onto you, complicating your job, etc, I agree, |
6 |
>and actually is what I was getting at in the badly worded section |
7 |
>below |
8 |
> |
9 |
> |
10 |
> |
11 |
>>>> My point is pretty simple, |
12 |
>>>>why should we spend a bunch of time maintaining something that is |
13 |
>>>>designed from the start to be customized, and most likely won't even be |
14 |
>>>>used anyway? |
15 |
>>>> |
16 |
>>>> |
17 |
>>>That's the issue; the profiles in their current form are customizable |
18 |
>>>only in the ability to negate a collection of flags. |
19 |
>>>Negating the whole beast is another story due to the desktop cruft |
20 |
>>>being shoved into the arch subprofiles. |
21 |
>>> |
22 |
>>> |
23 |
>>Sorry, but this didn't make a bit of sense to me. Perhaps you could |
24 |
>>reword it? |
25 |
>> |
26 |
>> |
27 |
>Basically stating that if I want the minimal 2005.1 x86 profile to |
28 |
>build my own server profile off of, I can't really use the existing |
29 |
>default-linux/x86/2005.1 ; |
30 |
> |
31 |
>Why? Mainly due to the fact that I would be forced to reverse a *lot* |
32 |
>of stuff, use flags mainly, to get it back down to a minimal profile. |
33 |
>That's what I mean by lack of customization; it can be done, but it's |
34 |
>not optimal, vs say inheriting a base default/x86/2005.1 that holds |
35 |
>just system defaults (pam, cflags, etc). |
36 |
> |
37 |
>If I were to implement a server profile from existing, I'd probably |
38 |
>tag in -* to the use, and add the use flags I explicitly want; that's |
39 |
>not really the best way to use the profiles inheritance capabilities |
40 |
>though :) |
41 |
> |
42 |
> |
43 |
> |
44 |
>>>Profile customization occurs, /etc/portage/profiles exists for this |
45 |
>>>reason; the 2005.1 profile (fex) is probably *rarely* ran exactly as |
46 |
>>>y'all have it specified considering we do have user level use flags, |
47 |
>>>tweaking the hell out of '05.1. |
48 |
>>> |
49 |
>>> |
50 |
>>You would be surprised at the number of people that use GRP and rarely, |
51 |
>>if ever, change their USE flags. I wish I had numbers, but I don't. |
52 |
>> |
53 |
>>Anyway, the default set of USE flags seems to be a pretty perfect mix |
54 |
>>for most people. It gives packages that work as expected, and is geared |
55 |
>>toward a desktop system. Without any more specific examples of what |
56 |
>>you're trying to point out, I'm just not seeing it. |
57 |
>> |
58 |
>> |
59 |
>Key thing to note, neither of us have figures :) |
60 |
>Beyond that, I'm not after castrating the defaults that exist, I'm |
61 |
>after sticking a level of indirection, a subprofile into the releng |
62 |
>profile inheritance chain so that if I *want* a minimal profile (as |
63 |
>you use), I can get it without having to resort to -* and tracking all |
64 |
>of the changes myself. |
65 |
> |
66 |
>It's a time saving effort; add multiple inheritance in, and it's easy |
67 |
>to do (win/win). |
68 |
> |
69 |
> |
70 |
> |
71 |
It'd be very handy , what if we setup a limit of subprofiles so to avoid |
72 |
people requesting other subprofiles?, and at the same time we can take more |
73 |
advantage of this idea? |
74 |
|
75 |
For example, we could have, a minimal, a default, and a custom subprofile. |
76 |
|
77 |
minimal would contain , well, as the word says, the minimal configuration, |
78 |
so everyone willing to have only "USE=-* basic-stuff" , can get it out |
79 |
of the box. |
80 |
|
81 |
default would be the profile which releng link the releases against. Our |
82 |
current |
83 |
profile. |
84 |
|
85 |
custom would be some way of people to tweak and do whatever they want .. |
86 |
this would be |
87 |
more like a way to give some kind of organization. |
88 |
|
89 |
With this kind of structure, we are still pretty general to fall into a |
90 |
"I want a Gnome profile" , |
91 |
but we can still take advantage of the feature for specific needs, and |
92 |
makes easier in such |
93 |
a way. |
94 |
|
95 |
|
96 |
|
97 |
-- |
98 |
gentoo-dev@g.o mailing list |