| 1 |
On 08/14/2012 03:21 PM, Andreas K. Huettel wrote: |
| 2 |
> Am Dienstag, 14. August 2012, 23:55:47 schrieb Zac Medico: |
| 3 |
>> It seems like there's some confusion here. Approving a new EAPI and |
| 4 |
>> deciding to use a new EAPI in a given profile are two entirely different |
| 5 |
>> things. If we want to us a new EAPI in a profile, we just have to deploy |
| 6 |
>> it such that users are only exposed to that profile when they |
| 7 |
>> consciously running `eselect profile` (and they can always revert back |
| 8 |
>> to the previous profile if it turns out that their installed package |
| 9 |
>> manager doesn't support the new profile). |
| 10 |
> |
| 11 |
> Yeah but... either |
| 12 |
> 1) we use such an obscure profile that noone actually notices the change, or |
| 13 |
> 2) we try to change something in the "big, well-known profiles", |
| 14 |
> and then we're back at the start. |
| 15 |
> |
| 16 |
> So what good is including a feature in a new profile if there is no way to |
| 17 |
> make it visible to "the users" in general? |
| 18 |
|
| 19 |
You do it in all the new profiles, and deprecate the old profiles. Users |
| 20 |
see the profile deprecation notice (or news item or other announcement) |
| 21 |
and upgrade their profile. |
| 22 |
|
| 23 |
> Also, in this particular case, "stable use masking" is useful because it makes |
| 24 |
> stabilization possible/simpler in cases where otherwise this would lead to |
| 25 |
> broken dependencies (stable depending on ~arch). If only one small sub-profile |
| 26 |
> provides the feature, we lose its whole advantage. |
| 27 |
|
| 28 |
Yeah, that's why I'm saying to do it in *all* new profiles and deprecate |
| 29 |
the old ones. |
| 30 |
-- |
| 31 |
Thanks, |
| 32 |
Zac |
Archives