| 1 |
On 02/02/17 08:21 PM, Michael Orlitzky wrote: |
| 2 |
> On 02/02/2017 06:41 PM, Ian Stakenvicius wrote: |
| 3 |
>> Responding here instead of the first time it was posted, just 'cause. |
| 4 |
>> |
| 5 |
>> On 02/02/17 06:35 PM, james wrote: |
| 6 |
>>> " |
| 7 |
>>> I'm not saying that we should have a minimal experience out-of-the-box, |
| 8 |
>>> only that the base profile should result in an effectively-minimal set |
| 9 |
>>> of USE flags. Adding IUSE defaults is essentially adding defaults to the |
| 10 |
>>> base profile." |
| 11 |
>> |
| 12 |
>> Yes. More specifically, it's adding these defaults without setting |
| 13 |
>> the flags globally, thereby not introducing system-wide defaults |
| 14 |
>> across all packages but only those that make sense on a per-package |
| 15 |
>> basis for that package to operate properly. |
| 16 |
>> |
| 17 |
>> IMO this is the effectively minimal-set of use flags we should have. |
| 18 |
> |
| 19 |
> I... agree? We should enable the flags that are necessary for the |
| 20 |
> package to work, and we should enable whatever is necessary to avoid |
| 21 |
> REQUIRED_USE roadblocks. That's what I started out by suggesting. |
| 22 |
> |
| 23 |
|
| 24 |
Where we disagree is that this includes all of scenarios #2, #3, and |
| 25 |
#4 IMO. #4 perhaps less so than the others, but IMO if there is a |
| 26 |
good reason feature-wise for that to be default-enabled, then the |
| 27 |
maintainer should still default-enable it and do so via IUSE-defaults. |
| 28 |
|
| 29 |
Remember one of the primary reasons IUSE-defaults came about is |
| 30 |
because maintainers were doing all of these things, but using "no*" |
| 31 |
flags so that the features would be default-enabled. I don't think |
| 32 |
any of us want to see that again. |
Archives