| 1 |
On Friday, February 3, 2017 2:53:59 PM EST Michael Orlitzky wrote: |
| 2 |
> On 02/03/2017 01:33 PM, Patrick McLean wrote: |
| 3 |
> > We might as well go back to before IUSE defaults then. Part of the |
| 4 |
> > advantage of IUSE defaults is maintainers don't all have to fiddle with |
| 5 |
> > the profiles, everything can be self-contained in the ebuild. This |
| 6 |
> > drastically complicates maintenance, having two locations to track and |
| 7 |
> > change rather than just one. |
| 8 |
> |
| 9 |
> You still retain the benefit for IUSE defaults that actually belong in |
| 10 |
> the base profile, just not for upstream defaults or the ones that you |
| 11 |
> personally prefer. |
| 12 |
|
| 13 |
That is a side effect, as it is more about the package maintainer choosing the |
| 14 |
defaults. They are not messing with profiles. That base ends up with it is |
| 15 |
indirect. Otherwise IUSE default flags would have to be per profile rather than |
| 16 |
in the package. Which would create more work for package maintainers. |
| 17 |
|
| 18 |
> > I suspect that there is a small subset |
| 19 |
> > of people interested in this, and perhaps those people could maintain a |
| 20 |
> > "minimal" profile that unsets IUSE defaults. |
| 21 |
> |
| 22 |
> Then every IUSE default gets recorded twice: once when the maintainer |
| 23 |
> puts it in the ebuild, and once when I add it (negated) to the minimal |
| 24 |
> profile. That's a bad design even if we pretend that I can solve the |
| 25 |
> problem of tracking every IUSE change in the tree. |
| 26 |
|
| 27 |
Sorry if its been suggested, I haven't followed every comment. What about some |
| 28 |
global env variable that could override all default IUSE. That can set in |
| 29 |
base, and set what ever minimal IUSE flags that are needed. |
| 30 |
|
| 31 |
-- |
| 32 |
William L. Thomson Jr. |
Archives