1 |
On Sat, 2019-09-21 at 08:43 +0200, Fabian Groffen wrote: |
2 |
> On 20-09-2019 22:53:53 +0200, Michał Górny wrote: |
3 |
> > On Fri, 2019-09-20 at 13:46 -0700, Zac Medico wrote: |
4 |
> > > If we take this underscore rule to its logical extreme, then we should |
5 |
> > > rename python_targets_python3_7 to python_targets_python3-7, yes? |
6 |
> > |
7 |
> > Believe me, I would have done that already if not the fact that with all |
8 |
> > the dependency logic around here it would be totally destructive to all |
9 |
> > Gentoo systems. |
10 |
> |
11 |
> Honestly, with this reasoning, why force other packages to go through |
12 |
> USE-flag renaming in that case? A major consumer of USE_EXPAND isn't |
13 |
> sticking to the rule, which makes any benefit of it moot. Tools cannot |
14 |
> assume the last underscore separates the USE_EXPAND var from its value, |
15 |
> users cannot see what is the value either, without knowledge. |
16 |
|
17 |
The major consumer is fixable. Sure, it will take years but that's |
18 |
better than leaving things wrong forever and saying wrong is good. |
19 |
|
20 |
> Why not teach our tools (equery, quse, etc.) to print these USE-flags |
21 |
> like Portage does? (looking them up to be valid expands) |
22 |
> Then users have nothing to be confused about (no distinction between |
23 |
> foo_bar and FOO="bar"), and new USE_EXPANDS cannot be |
24 |
> silently/accidentially introduced. |
25 |
|
26 |
I don't see how that solves the problem. More tools having distinct |
27 |
output don't change the fact that anyone with a bit of ebuild knowledge |
28 |
will say 'this looks like USE_EXPAND' while looking at it, independently |
29 |
of what some tools would say. |
30 |
|
31 |
-- |
32 |
Best regards, |
33 |
Michał Górny |