1 |
On Tue, Jun 13, 2006 at 06:28:41PM +0100, Stephen Bennett wrote: |
2 |
> Brian Harring wrote: |
3 |
> >The gain of the profile is that you can do a few new tricks for folks |
4 |
> >doing boostrapping experiments- why not just introduce an ebuild that |
5 |
> >sets up the new profile in a temp overlay? |
6 |
> |
7 |
> No, the gain is that one could sanely run a Paludis-based system without |
8 |
> needing an external overlay, and without having to update said overlay |
9 |
> whenever the base profiles in the tree change. |
10 |
|
11 |
Bluntly, why should the tree be modified for a minority? Being |
12 |
generous, lets pretend y'all have 300 users- why should incompatible |
13 |
changes be added to the tree (say 300k users) that can bite 299,700 |
14 |
users in the ass for the benefit of 300 users? N parent inherited |
15 |
profiles *is* a change that can bite users in the ass, and it's not an |
16 |
obvious incompatibility unless you know it exists. |
17 |
|
18 |
Ebuild level incompatibility is there also, and the only way that's |
19 |
going to be resolved is by inspection of each ebuild. |
20 |
|
21 |
Note I said inspection- just the same as loosing the USE flag state |
22 |
for when re-executing the env for an unmerge, loosing local non |
23 |
exported vars has the same potential for change. |
24 |
|
25 |
Not opposed to y'all ironing it out in an overlay and proposing the |
26 |
switch (with a sane transition plan)- am opposed to the "lets just do |
27 |
it and ignore the consequences to the userbase" mentality that such |
28 |
requests imply. |
29 |
|
30 |
~harring |