Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On 12/17/18 7:51 AM, Michał Górny wrote: > On Mon, 2018-12-17 at 15:44 +, M. J. Everitt wrote: >> On 17/12/18 12:54, Michał Górny wrote: Not only this, but as noted, unless you know the man pages for portage and make.conf in order to recite them in your sleep, they are confusing for users, as they do not necessarily follow an obvious pattern, and it wasn't until I was attempting to debug something that I noticed that despite believing I had the correct settings in my make.conf (set over a period of YEARS) they were in fact completely useless, and it wasn't until I had to spend time with somebody debugging WTF was happening, that this particular issue even became apparent... >>> >>> I don't see how this is an argument for anything. You have to read >>> the manual in order to know that such variable exists and what it does. >>> Or, well, technically you don't since it's provided in make.conf.example >>> already where you only need to uncomment it. >>> >>> Either way, the variable name is trivial. Even if you don't follow >>> the usual pattern of uncommenting it from make.conf.example or copying >>> from the manual, remembering it for the time needed to retype shoudln't >>> be a problem. >>> >>> So, is this a solution to a real problem? Or is it merely a half- >>> thought-out partial change that's going to require people to update >>> their configuration for no long-term benefit? And then they will have >>> to update it again when someone decides to take another variable for >>> a spin. >>> >> >> In the case you hadn't noticed, clearly you haven't .. the change is >> backwards compatible.. that has already been thought out. >> >> But you haven't actually looked at the patch have you, Michal ? >> > > I did look at it. However, that doesn't change what I said. Being > 'backwards compatible' does not change the fact that the old variable > becomes deprecated now. Ergo, users are expected to eventually switch > to the new one. > > Even if you don't care beyond changing this now and forgetting about it > afterwards, someone eventually will have to clean up the old variable > and actively force people to update. Let's comment out the UserWarning message for now, and we can enable it at some point in the future when people have forgotten that PORT_LOGDIR was a thing. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On Mon, 2018-12-17 at 21:09 -0500, Alec Warner wrote: > On Mon, Dec 17, 2018 at 10:51 AM Michał Górny wrote: > > > On Mon, 2018-12-17 at 15:44 +, M. J. Everitt wrote: > > > On 17/12/18 12:54, Michał Górny wrote: > > > > > Not only this, but as noted, unless you know the man pages for > > > > portage and > > > > > make.conf in order to recite them in your sleep, they are confusing > > > > for > > > > > users, as they do not necessarily follow an obvious pattern, and it > > > > wasn't > > > > > until I was attempting to debug something that I noticed that despite > > > > > believing I had the correct settings in my make.conf (set over a > > > > period of > > > > > YEARS) they were in fact completely useless, and it wasn't until I > > > > had to > > > > > spend time with somebody debugging WTF was happening, that this > > > > particular > > > > > issue even became apparent... > > > > > > > > I don't see how this is an argument for anything. You have to read > > > > the manual in order to know that such variable exists and what it > > > > does. > > > > Or, well, technically you don't since it's provided in > > > > make.conf.example > > > > already where you only need to uncomment it. > > > > > > > > Either way, the variable name is trivial. Even if you don't follow > > > > the usual pattern of uncommenting it from make.conf.example or copying > > > > from the manual, remembering it for the time needed to retype shoudln't > > > > be a problem. > > > > > > > > So, is this a solution to a real problem? Or is it merely a half- > > > > thought-out partial change that's going to require people to update > > > > their configuration for no long-term benefit? And then they will have > > > > to update it again when someone decides to take another variable for > > > > a spin. > > > > > > > > > > In the case you hadn't noticed, clearly you haven't .. the change is > > > backwards compatible.. that has already been thought out. > > > > > > But you haven't actually looked at the patch have you, Michal ? > > > > > > > I did look at it. However, that doesn't change what I said. Being > > 'backwards compatible' does not change the fact that the old variable > > becomes deprecated now. Ergo, users are expected to eventually switch > > to the new one. > > > > So if we rewrote the patches to not deprecate the old one but to support > both; how would that strike you? > As a horrible idea, violating SPOT rule? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On Mon, Dec 17, 2018 at 10:51 AM Michał Górny wrote: > On Mon, 2018-12-17 at 15:44 +, M. J. Everitt wrote: > > On 17/12/18 12:54, Michał Górny wrote: > > > > Not only this, but as noted, unless you know the man pages for > portage and > > > > make.conf in order to recite them in your sleep, they are confusing > for > > > > users, as they do not necessarily follow an obvious pattern, and it > wasn't > > > > until I was attempting to debug something that I noticed that despite > > > > believing I had the correct settings in my make.conf (set over a > period of > > > > YEARS) they were in fact completely useless, and it wasn't until I > had to > > > > spend time with somebody debugging WTF was happening, that this > particular > > > > issue even became apparent... > > > > > > I don't see how this is an argument for anything. You have to read > > > the manual in order to know that such variable exists and what it > does. > > > Or, well, technically you don't since it's provided in > make.conf.example > > > already where you only need to uncomment it. > > > > > > Either way, the variable name is trivial. Even if you don't follow > > > the usual pattern of uncommenting it from make.conf.example or copying > > > from the manual, remembering it for the time needed to retype shoudln't > > > be a problem. > > > > > > So, is this a solution to a real problem? Or is it merely a half- > > > thought-out partial change that's going to require people to update > > > their configuration for no long-term benefit? And then they will have > > > to update it again when someone decides to take another variable for > > > a spin. > > > > > > > In the case you hadn't noticed, clearly you haven't .. the change is > > backwards compatible.. that has already been thought out. > > > > But you haven't actually looked at the patch have you, Michal ? > > > > I did look at it. However, that doesn't change what I said. Being > 'backwards compatible' does not change the fact that the old variable > becomes deprecated now. Ergo, users are expected to eventually switch > to the new one. > So if we rewrote the patches to not deprecate the old one but to support both; how would that strike you? -A > > Even if you don't care beyond changing this now and forgetting about it > afterwards, someone eventually will have to clean up the old variable > and actively force people to update. > -- > Best regards, > Michał Górny >
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On 17/12/18 15:51, Michał Górny wrote: > On Mon, 2018-12-17 at 15:44 +, M. J. Everitt wrote: >> On 17/12/18 12:54, Michał Górny wrote: Not only this, but as noted, unless you know the man pages for portage and make.conf in order to recite them in your sleep, they are confusing for users, as they do not necessarily follow an obvious pattern, and it wasn't until I was attempting to debug something that I noticed that despite believing I had the correct settings in my make.conf (set over a period of YEARS) they were in fact completely useless, and it wasn't until I had to spend time with somebody debugging WTF was happening, that this particular issue even became apparent... >>> I don't see how this is an argument for anything. You have to read >>> the manual in order to know that such variable exists and what it does. >>> Or, well, technically you don't since it's provided in make.conf.example >>> already where you only need to uncomment it. >>> >>> Either way, the variable name is trivial. Even if you don't follow >>> the usual pattern of uncommenting it from make.conf.example or copying >>> from the manual, remembering it for the time needed to retype shoudln't >>> be a problem. >>> >>> So, is this a solution to a real problem? Or is it merely a half- >>> thought-out partial change that's going to require people to update >>> their configuration for no long-term benefit? And then they will have >>> to update it again when someone decides to take another variable for >>> a spin. >>> >> In the case you hadn't noticed, clearly you haven't .. the change is >> backwards compatible.. that has already been thought out. >> >> But you haven't actually looked at the patch have you, Michal ? >> > I did look at it. However, that doesn't change what I said. Being > 'backwards compatible' does not change the fact that the old variable > becomes deprecated now. Ergo, users are expected to eventually switch > to the new one. > > Even if you don't care beyond changing this now and forgetting about it > afterwards, someone eventually will have to clean up the old variable > and actively force people to update. > Correct, but surely this doesn't apply in any other areas of Gentoo, eg. perhaps Ebuilds? EAPIs? PMS? QA? signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On Mon, 2018-12-17 at 15:44 +, M. J. Everitt wrote: > On 17/12/18 12:54, Michał Górny wrote: > > > Not only this, but as noted, unless you know the man pages for portage and > > > make.conf in order to recite them in your sleep, they are confusing for > > > users, as they do not necessarily follow an obvious pattern, and it wasn't > > > until I was attempting to debug something that I noticed that despite > > > believing I had the correct settings in my make.conf (set over a period of > > > YEARS) they were in fact completely useless, and it wasn't until I had to > > > spend time with somebody debugging WTF was happening, that this particular > > > issue even became apparent... > > > > I don't see how this is an argument for anything. You have to read > > the manual in order to know that such variable exists and what it does. > > Or, well, technically you don't since it's provided in make.conf.example > > already where you only need to uncomment it. > > > > Either way, the variable name is trivial. Even if you don't follow > > the usual pattern of uncommenting it from make.conf.example or copying > > from the manual, remembering it for the time needed to retype shoudln't > > be a problem. > > > > So, is this a solution to a real problem? Or is it merely a half- > > thought-out partial change that's going to require people to update > > their configuration for no long-term benefit? And then they will have > > to update it again when someone decides to take another variable for > > a spin. > > > > In the case you hadn't noticed, clearly you haven't .. the change is > backwards compatible.. that has already been thought out. > > But you haven't actually looked at the patch have you, Michal ? > I did look at it. However, that doesn't change what I said. Being 'backwards compatible' does not change the fact that the old variable becomes deprecated now. Ergo, users are expected to eventually switch to the new one. Even if you don't care beyond changing this now and forgetting about it afterwards, someone eventually will have to clean up the old variable and actively force people to update. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On 17/12/18 15:44, M. J. Everitt wrote: > On 17/12/18 12:54, Michał Górny wrote: >>> Not only this, but as noted, unless you know the man pages for portage and >>> make.conf in order to recite them in your sleep, they are confusing for >>> users, as they do not necessarily follow an obvious pattern, and it wasn't >>> until I was attempting to debug something that I noticed that despite >>> believing I had the correct settings in my make.conf (set over a period of >>> YEARS) they were in fact completely useless, and it wasn't until I had to >>> spend time with somebody debugging WTF was happening, that this particular >>> issue even became apparent... >> I don't see how this is an argument for anything. You have to read >> the manual in order to know that such variable exists and what it does. >> Or, well, technically you don't since it's provided in make.conf.example >> already where you only need to uncomment it. >> >> Either way, the variable name is trivial. Even if you don't follow >> the usual pattern of uncommenting it from make.conf.example or copying >> from the manual, remembering it for the time needed to retype shoudln't >> be a problem. >> >> So, is this a solution to a real problem? Or is it merely a half- >> thought-out partial change that's going to require people to update >> their configuration for no long-term benefit? And then they will have >> to update it again when someone decides to take another variable for >> a spin. >> > In the case you hadn't noticed, clearly you haven't .. the change is > backwards compatible.. that has already been thought out. > > But you haven't actually looked at the patch have you, Michal ? > Whilst I'm here .. you won't also have noticed I've updated the documentation too ... signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On 17/12/18 12:54, Michał Górny wrote: >> Not only this, but as noted, unless you know the man pages for portage and >> make.conf in order to recite them in your sleep, they are confusing for >> users, as they do not necessarily follow an obvious pattern, and it wasn't >> until I was attempting to debug something that I noticed that despite >> believing I had the correct settings in my make.conf (set over a period of >> YEARS) they were in fact completely useless, and it wasn't until I had to >> spend time with somebody debugging WTF was happening, that this particular >> issue even became apparent... > I don't see how this is an argument for anything. You have to read > the manual in order to know that such variable exists and what it does. > Or, well, technically you don't since it's provided in make.conf.example > already where you only need to uncomment it. > > Either way, the variable name is trivial. Even if you don't follow > the usual pattern of uncommenting it from make.conf.example or copying > from the manual, remembering it for the time needed to retype shoudln't > be a problem. > > So, is this a solution to a real problem? Or is it merely a half- > thought-out partial change that's going to require people to update > their configuration for no long-term benefit? And then they will have > to update it again when someone decides to take another variable for > a spin. > In the case you hadn't noticed, clearly you haven't .. the change is backwards compatible.. that has already been thought out. But you haven't actually looked at the patch have you, Michal ? signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On Mon, 2018-12-17 at 05:12 +, M. J. Everitt wrote: > On 15/12/18 08:55, Michał Górny wrote: > > On Sat, 2018-12-15 at 02:25 +, M. J. Everitt wrote: > > > This patchset aims to fix potential ambiguity and confusion between older > > > PORT_LOG* variables, > > > and more recent PORTAGE_* variables - often leading to mysteriously > > > lacking logging due to > > > incorrect variable names. Documented in Bug 668538; with thanks to Zac > > > for diagnosis, and > > > solution assistance! > > > > > > > Does 'often' actually affect more than one person? Do you have any > > evidence to support this? > > > > Given that a lot of Portage variables don't have any prefix or sane > > names, I dare say this one doesn't especially stand out. > > > > Just a thought, but how about you apply your skill and wisdom to reviewing > the patches, instead of wasting it on writing snide replies? > Quite radical I know, but whadda ya think?! You didn't answer my question. However, given the level of aggression in your reply, I'm going to presume I've caught you on a blatant lie and that this problem affects exactly one person, yourself, and you are making an unnecessary change to bend the world to your mistake. > As it happens, I was going for consistency here, as that often reflects > code quality, and you being a keen QA member, I'da thought perhaps you > might have spotted this! Are you? Do you have any evidence to support that? Because as far as I can see (and it's even quite visible in your patch), none of the variables in the group with 'PORT_LOGDIR' in it use 'PORTAGE_' prefix. So are you improving consistency in variable naming, or are you replacing one inconsistency with another? > Not only this, but as noted, unless you know the man pages for portage and > make.conf in order to recite them in your sleep, they are confusing for > users, as they do not necessarily follow an obvious pattern, and it wasn't > until I was attempting to debug something that I noticed that despite > believing I had the correct settings in my make.conf (set over a period of > YEARS) they were in fact completely useless, and it wasn't until I had to > spend time with somebody debugging WTF was happening, that this particular > issue even became apparent... I don't see how this is an argument for anything. You have to read the manual in order to know that such variable exists and what it does. Or, well, technically you don't since it's provided in make.conf.example already where you only need to uncomment it. Either way, the variable name is trivial. Even if you don't follow the usual pattern of uncommenting it from make.conf.example or copying from the manual, remembering it for the time needed to retype shoudln't be a problem. So, is this a solution to a real problem? Or is it merely a half- thought-out partial change that's going to require people to update their configuration for no long-term benefit? And then they will have to update it again when someone decides to take another variable for a spin. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On 15/12/18 08:55, Michał Górny wrote: > On Sat, 2018-12-15 at 02:25 +, M. J. Everitt wrote: >> This patchset aims to fix potential ambiguity and confusion between older >> PORT_LOG* variables, >> and more recent PORTAGE_* variables - often leading to mysteriously lacking >> logging due to >> incorrect variable names. Documented in Bug 668538; with thanks to Zac for >> diagnosis, and >> solution assistance! >> > Does 'often' actually affect more than one person? Do you have any > evidence to support this? > > Given that a lot of Portage variables don't have any prefix or sane > names, I dare say this one doesn't especially stand out. > Just a thought, but how about you apply your skill and wisdom to reviewing the patches, instead of wasting it on writing snide replies? Quite radical I know, but whadda ya think?! As it happens, I was going for consistency here, as that often reflects code quality, and you being a keen QA member, I'da thought perhaps you might have spotted this! Not only this, but as noted, unless you know the man pages for portage and make.conf in order to recite them in your sleep, they are confusing for users, as they do not necessarily follow an obvious pattern, and it wasn't until I was attempting to debug something that I noticed that despite believing I had the correct settings in my make.conf (set over a period of YEARS) they were in fact completely useless, and it wasn't until I had to spend time with somebody debugging WTF was happening, that this particular issue even became apparent... signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On Sat, 2018-12-15 at 02:25 +, M. J. Everitt wrote: > This patchset aims to fix potential ambiguity and confusion between older > PORT_LOG* variables, > and more recent PORTAGE_* variables - often leading to mysteriously lacking > logging due to > incorrect variable names. Documented in Bug 668538; with thanks to Zac for > diagnosis, and > solution assistance! > Does 'often' actually affect more than one person? Do you have any evidence to support this? Given that a lot of Portage variables don't have any prefix or sane names, I dare say this one doesn't especially stand out. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
This patchset aims to fix potential ambiguity and confusion between older PORT_LOG* variables, and more recent PORTAGE_* variables - often leading to mysteriously lacking logging due to incorrect variable names. Documented in Bug 668538; with thanks to Zac for diagnosis, and solution assistance! M. J. Everitt (4): Renamed PORT_LOGDIR[_CLEAN] to PORTAGE_LOGDIR[_CLEAN] Provide compatibility support for old PORT_LOGDIR* variable names Update documentation for PORT_LOGDIR* changes Add note to NEWS/ChangeLog for PORT_LOGDIR* changes NEWS | 8 +++- cnf/make.conf.example | 12 +++--- cnf/make.globals | 2 +- lib/_emerge/post_emerge.py | 2 +- lib/portage/dbapi/vartree.py | 2 +- lib/portage/elog/mod_echo.py | 2 +- lib/portage/elog/mod_save.py | 4 +- lib/portage/elog/mod_save_summary.py | 4 +- lib/portage/emaint/modules/logs/__init__.py| 2 +- lib/portage/emaint/modules/logs/logs.py| 22 +-- .../package/ebuild/_config/special_env_vars.py | 2 +- lib/portage/package/ebuild/config.py | 11 ++ lib/portage/package/ebuild/prepare_build_dirs.py | 26 ++-- lib/portage/tests/emerge/test_simple.py| 2 +- man/ebuild.5 | 2 +- man/emaint.1 | 6 +-- man/emerge.1 | 2 +- man/make.conf.5| 46 -- 18 files changed, 90 insertions(+), 67 deletions(-) -- 2.13.6 signature.asc Description: OpenPGP digital signature
