| 1 |
On Mon, 2018-12-17 at 05:12 +0000, M. J. Everitt wrote: |
| 2 |
> On 15/12/18 08:55, Michał Górny wrote: |
| 3 |
> > On Sat, 2018-12-15 at 02:25 +0000, M. J. Everitt wrote: |
| 4 |
> > > This patchset aims to fix potential ambiguity and confusion between older PORT_LOG* variables, |
| 5 |
> > > and more recent PORTAGE_* variables - often leading to mysteriously lacking logging due to |
| 6 |
> > > incorrect variable names. Documented in Bug 668538; with thanks to Zac for diagnosis, and |
| 7 |
> > > solution assistance! |
| 8 |
> > > |
| 9 |
> > |
| 10 |
> > Does 'often' actually affect more than one person? Do you have any |
| 11 |
> > evidence to support this? |
| 12 |
> > |
| 13 |
> > Given that a lot of Portage variables don't have any prefix or sane |
| 14 |
> > names, I dare say this one doesn't especially stand out. |
| 15 |
> > |
| 16 |
> |
| 17 |
> Just a thought, but how about you apply your skill and wisdom to reviewing |
| 18 |
> the patches, instead of wasting it on writing snide replies? |
| 19 |
> Quite radical I know, but whadda ya think?! |
| 20 |
|
| 21 |
You didn't answer my question. However, given the level of aggression |
| 22 |
in your reply, I'm going to presume I've caught you on a blatant lie |
| 23 |
and that this problem affects exactly one person, yourself, and you are |
| 24 |
making an unnecessary change to bend the world to your mistake. |
| 25 |
|
| 26 |
> As it happens, I was going for consistency here, as that often reflects |
| 27 |
> code quality, and you being a keen QA member, I'da thought perhaps you |
| 28 |
> might have spotted this! |
| 29 |
|
| 30 |
Are you? Do you have any evidence to support that? Because as far as I |
| 31 |
can see (and it's even quite visible in your patch), none of |
| 32 |
the variables in the group with 'PORT_LOGDIR' in it use 'PORTAGE_' |
| 33 |
prefix. So are you improving consistency in variable naming, or are you |
| 34 |
replacing one inconsistency with another? |
| 35 |
|
| 36 |
> Not only this, but as noted, unless you know the man pages for portage and |
| 37 |
> make.conf in order to recite them in your sleep, they are confusing for |
| 38 |
> users, as they do not necessarily follow an obvious pattern, and it wasn't |
| 39 |
> until I was attempting to debug something that I noticed that despite |
| 40 |
> believing I had the correct settings in my make.conf (set over a period of |
| 41 |
> YEARS) they were in fact completely useless, and it wasn't until I had to |
| 42 |
> spend time with somebody debugging WTF was happening, that this particular |
| 43 |
> issue even became apparent... |
| 44 |
|
| 45 |
I don't see how this is an argument for anything. You have to read |
| 46 |
the manual in order to know that such variable exists and what it does. |
| 47 |
Or, well, technically you don't since it's provided in make.conf.example |
| 48 |
already where you only need to uncomment it. |
| 49 |
|
| 50 |
Either way, the variable name is trivial. Even if you don't follow |
| 51 |
the usual pattern of uncommenting it from make.conf.example or copying |
| 52 |
from the manual, remembering it for the time needed to retype shoudln't |
| 53 |
be a problem. |
| 54 |
|
| 55 |
So, is this a solution to a real problem? Or is it merely a half- |
| 56 |
thought-out partial change that's going to require people to update |
| 57 |
their configuration for no long-term benefit? And then they will have |
| 58 |
to update it again when someone decides to take another variable for |
| 59 |
a spin. |
| 60 |
|
| 61 |
-- |
| 62 |
Best regards, |
| 63 |
Michał Górny |
Archives