| 1 |
On 02/03/2017 02:09 PM, William L. Thomson Jr. wrote: |
| 2 |
> On Friday, February 3, 2017 2:53:59 PM EST Michael Orlitzky wrote: |
| 3 |
>> On 02/03/2017 01:33 PM, Patrick McLean wrote: |
| 4 |
>>> We might as well go back to before IUSE defaults then. Part of the |
| 5 |
>>> advantage of IUSE defaults is maintainers don't all have to fiddle with |
| 6 |
>>> the profiles, everything can be self-contained in the ebuild. This |
| 7 |
>>> drastically complicates maintenance, having two locations to track and |
| 8 |
>>> change rather than just one. |
| 9 |
>> |
| 10 |
>> You still retain the benefit for IUSE defaults that actually belong in |
| 11 |
>> the base profile, just not for upstream defaults or the ones that you |
| 12 |
>> personally prefer. |
| 13 |
> |
| 14 |
> That is a side effect, as it is more about the package maintainer choosing the |
| 15 |
> defaults. They are not messing with profiles. That base ends up with it is |
| 16 |
> indirect. Otherwise IUSE default flags would have to be per profile rather than |
| 17 |
> in the package. Which would create more work for package maintainers. |
| 18 |
> |
| 19 |
>>> I suspect that there is a small subset |
| 20 |
>>> of people interested in this, and perhaps those people could maintain a |
| 21 |
>>> "minimal" profile that unsets IUSE defaults. |
| 22 |
>> |
| 23 |
>> Then every IUSE default gets recorded twice: once when the maintainer |
| 24 |
>> puts it in the ebuild, and once when I add it (negated) to the minimal |
| 25 |
>> profile. That's a bad design even if we pretend that I can solve the |
| 26 |
>> problem of tracking every IUSE change in the tree. |
| 27 |
> |
| 28 |
> Sorry if its been suggested, I haven't followed every comment. What about some |
| 29 |
> global env variable that could override all default IUSE. That can set in |
| 30 |
> base, and set what ever minimal IUSE flags that are needed. |
| 31 |
> |
| 32 |
I support the idea of a profile-set variable that determines whether or |
| 33 |
not IUSE is respected. Minimalists get their systems faster, we get |
| 34 |
something that adds to Gentoo's versatility and an additional profile. |
| 35 |
Of course, we should be asking the anti-IUSE people if that would be |
| 36 |
good enough to make the profiles/systems they want possible. |
| 37 |
|
| 38 |
-- |
| 39 |
Daniel Campbell - Gentoo Developer |
| 40 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
| 41 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |
Archives