[pacman-dev] [PATCH] scripts/library: fix typo in README
Simply fix a typo: in written -> is written
Signed-off-by: Michael Straube
Colorize [installed] and [pending] when printing optional dependencies.
FS#34920
Signed-off-by: Michael Straube
Change the warning message to reflect the reason when skipping duplicate
targets. skipping target -> skipping duplicate target
FS#49377
Signed-off-by: Michael Straube
On 12/09/18 at 06:31pm, Michael Straube wrote:
Change the warning message to reflect the reason when skipping duplicate targets. skipping target -> skipping duplicate target
FS#49377
Signed-off-by: Michael Straube
--- src/pacman/remove.c | 2 +- src/pacman/sync.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Should we just remove the error altogether and move the message to DEBUG? The user doesn't need to do anything in response to it and I can't think of any reason a front-end would want to actually die from it. It seems to just be useless line noise that requires front-ends to check for it specifically just to ignore it.
Am 09.12.18 um 19:47 schrieb Andrew Gregory:
On 12/09/18 at 06:31pm, Michael Straube wrote:
Change the warning message to reflect the reason when skipping duplicate targets. skipping target -> skipping duplicate target
FS#49377
Signed-off-by: Michael Straube
--- src/pacman/remove.c | 2 +- src/pacman/sync.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Should we just remove the error altogether and move the message to DEBUG? The user doesn't need to do anything in response to it and I can't think of any reason a front-end would want to actually die from it. It seems to just be useless line noise that requires front-ends to check for it specifically just to ignore it.
Sounds reasonable. On the other hand I can imagine that some people would complain that too much from what's going on is hidden from the user. What do others think? P.S.: You mean? pm_printf(ALPM_LOG_DEBUG, _("skipping duplicate target: %s\n"), target);
On 12/11/18 at 06:14pm, Michael Straube wrote:
Am 09.12.18 um 19:47 schrieb Andrew Gregory:
On 12/09/18 at 06:31pm, Michael Straube wrote:
Change the warning message to reflect the reason when skipping duplicate targets. skipping target -> skipping duplicate target
FS#49377
Signed-off-by: Michael Straube
--- src/pacman/remove.c | 2 +- src/pacman/sync.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Should we just remove the error altogether and move the message to DEBUG? The user doesn't need to do anything in response to it and I can't think of any reason a front-end would want to actually die from it. It seems to just be useless line noise that requires front-ends to check for it specifically just to ignore it.
Sounds reasonable. On the other hand I can imagine that some people would complain that too much from what's going on is hidden from the user. What do others think?
P.S.: You mean? pm_printf(ALPM_LOG_DEBUG, _("skipping duplicate target: %s\n"), target);
I realized after sending this that adding a duplicate could actually be an error if they are two separate packages with the same name. So, I'm going to say to add a check in add_pkg for whether the duplicate is actually the same package (simple pointer cmp) and, if they are the same, log a debug message and return success, if they are different return the error as we do now. process_pkg in pacman should then treat that error just like any other instead of printing a warning and continuing on. alpm_remove_pkg should just log the debug message and return success. apg
Am 11.12.18 um 20:51 schrieb Andrew Gregory:
On 12/11/18 at 06:14pm, Michael Straube wrote:
Am 09.12.18 um 19:47 schrieb Andrew Gregory:
On 12/09/18 at 06:31pm, Michael Straube wrote:
Change the warning message to reflect the reason when skipping duplicate targets. skipping target -> skipping duplicate target
FS#49377
Signed-off-by: Michael Straube
--- src/pacman/remove.c | 2 +- src/pacman/sync.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Should we just remove the error altogether and move the message to DEBUG? The user doesn't need to do anything in response to it and I can't think of any reason a front-end would want to actually die from it. It seems to just be useless line noise that requires front-ends to check for it specifically just to ignore it.
Sounds reasonable. On the other hand I can imagine that some people would complain that too much from what's going on is hidden from the user. What do others think?
P.S.: You mean? pm_printf(ALPM_LOG_DEBUG, _("skipping duplicate target: %s\n"), target);
I realized after sending this that adding a duplicate could actually be an error if they are two separate packages with the same name. So, I'm going to say to add a check in add_pkg for whether the duplicate is actually the same package (simple pointer cmp) and, if they are the same, log a debug message and return success, if they are different return the error as we do now. process_pkg in pacman should then treat that error just like any other instead of printing a warning and continuing on. alpm_remove_pkg should just log the debug message and return success.
apg
Ok, I will send a patch the next days.
On 10/12/18 3:31 am, Michael Straube wrote:
Colorize [installed] and [pending] when printing optional dependencies.
FS#34920
Signed-off-by: Michael Straube
---
Thanks for this patch. I think there was a reason this bug was sitting untouched since 2013... To me, adding colour here is very distracting during an update: http://allanmcrae.com/tmp/color.png I'd prefer having less colours in our search operations, rather than bringing those colours into other operations. Anyone want to give other opinions on this? Allan
On 12 Dec 2018, at 11:31 am +1000, Allan McRae wrote:
On 10/12/18 3:31 am, Michael Straube wrote:
Colorize [installed] and [pending] when printing optional dependencies.
I'd prefer having less colours in our search operations, rather than bringing those colours into other operations.
Anyone want to give other opinions on this?
Agreed; I tend to prefer black-and-white output. Also, tools like lesspipe and multitail can colorize any program's stdout without having to add color support to the original program (or in this case, further complicate existing color support). Cheers, Ivy ("escondida")
Am 12.12.18 um 03:29 schrieb Ivy Foster:
On 12 Dec 2018, at 11:31 am +1000, Allan McRae wrote:
On 10/12/18 3:31 am, Michael Straube wrote:
Colorize [installed] and [pending] when printing optional dependencies.
I'd prefer having less colours in our search operations, rather than bringing those colours into other operations.
Anyone want to give other opinions on this?
Agreed; I tend to prefer black-and-white output. Also, tools like lesspipe and multitail can colorize any program's stdout without having to add color support to the original program (or in this case, further complicate existing color support).
Cheers, Ivy ("escondida")
I also think it can be irritating and/or distracting. In terms of simplicity I agree with Ivy. Well, the bug was on the list for v6.0, so I thought it was wanted to implement. ;) Michael
participants (4)
-
Allan McRae
-
Andrew Gregory
-
Ivy Foster
-
Michael Straube