Hello.
A really small change in pacman which, I hope, improves the feedback about explicit packages on install/removal/update.
Have a nice day.
Output of git format-patch origin:
From bd5c3aa7826c3c073cca691f0e30b5363487cd6f Mon Sep 17 00:00:00 2001
From: Guillaume Bouchard guillaum.bouchard@gmail.com Date: Fri, 24 Jan 2014 12:20:16 +0100 Subject: [PATCH] Put explicitly installed packages in bold during update/install/removal
In extended table view, packages which are explicitly installed are displayed as CELL_TITLE (i.e. in bold). This helps understanding why packages are updated.
This helps the package managment workflow. During update, we can quickly have a look at why packages are updated and easilly track and remove the explicit packages which are not longer required. During remove, it shows all the explicit packages which are also removed by a cascade removal. During install, it provides a feedback on how your action will affect the database.
This only affects "VerbosePkgLists" output. Patching the un-verbose output appears more difficult and I think this information is only interesting during verbose output.
Signed-off-by: Guillaume Bouchard guillaum.bouchard@gmail.com --- src/pacman/util.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/pacman/util.c b/src/pacman/util.c index 58b0cec..a3ee5ee 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -808,7 +808,12 @@ static alpm_list_t *create_verbose_row(pm_target_t *target) } else { pm_asprintf(&str, "%s", alpm_pkg_get_name(target->remove)); } - add_table_cell(&ret, str, CELL_NORMAL); + if(alpm_pkg_get_reason(target->remove ? target->remove : target->install) == ALPM_PKG_REASON_EXPLICIT) { + /* put emphasis on the package name if it is an explicitly installed package */ + add_table_cell(&ret, str, CELL_TITLE); + } else { + add_table_cell(&ret, str, CELL_NORMAL); + }
/* old and new versions */ pm_asprintf(&str, "%s",
On 24.01.2014 12:36, Guillaume Bouchard wrote:
Output of git format-patch origin: [...]
- add_table_cell(&ret, str, CELL_NORMAL);
- if(alpm_pkg_get_reason(target->remove ? target->remove :
target->install) == ALPM_PKG_REASON_EXPLICIT) {
fatal: corrupt patch at line 15
Please submit patches with git send-email, otherwise you risk mangled whitespace (as happened here).
https://wiki.archlinux.org/index.php/Super_Quick_Git_Guide#Sending_patches
In extended table view, packages which are explicitly installed are displayed as CELL_TITLE (i.e. in bold). This helps understanding why packages are updated.
This helps the package managment workflow. During update, we can quickly have a look at why packages are updated and easilly track and remove the explicit packages which are not longer required. During remove, it shows all the explicit packages which are also removed by a cascade removal. During install, it provides a feedback on how your action will affect the database.
Signed-off-by: Guillaume Bouchard guillaum.bouchard@gmail.com --- src/pacman/util.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/pacman/util.c b/src/pacman/util.c index 58b0cec..a3ee5ee 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -808,7 +808,12 @@ static alpm_list_t *create_verbose_row(pm_target_t *target) } else { pm_asprintf(&str, "%s", alpm_pkg_get_name(target->remove)); } - add_table_cell(&ret, str, CELL_NORMAL); + if(alpm_pkg_get_reason(target->remove ? target->remove : target->install) == ALPM_PKG_REASON_EXPLICIT) { + /* put emphasis on the package name if it is an explicitly installed package */ + add_table_cell(&ret, str, CELL_TITLE); + } else { + add_table_cell(&ret, str, CELL_NORMAL); + }
/* old and new versions */ pm_asprintf(&str, "%s",
On Fri, Jan 24, 2014 at 2:17 PM, Guillaume Bouchard guillaum.bouchard@gmail.com wrote:
In extended table view, packages which are explicitly installed are displayed as CELL_TITLE (i.e. in bold). This helps understanding why packages are updated.
This helps the package managment workflow. During update, we can quickly have a look at why packages are updated and easilly track and remove the explicit packages which are not longer required. During remove, it shows all the explicit packages which are also removed by a cascade removal. During install, it provides a feedback on how your action will affect the database.
2¢ for the bikeshed: have you tried putting non-explicitly installed packages in grey instead? It might make more sense.
Signed-off-by: Guillaume Bouchard guillaum.bouchard@gmail.com
src/pacman/util.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/pacman/util.c b/src/pacman/util.c index 58b0cec..a3ee5ee 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -808,7 +808,12 @@ static alpm_list_t *create_verbose_row(pm_target_t *target) } else { pm_asprintf(&str, "%s", alpm_pkg_get_name(target->remove)); }
add_table_cell(&ret, str, CELL_NORMAL);
if(alpm_pkg_get_reason(target->remove ? target->remove : target->install) == ALPM_PKG_REASON_EXPLICIT) {/* put emphasis on the package name if it is an explicitly installed package */add_table_cell(&ret, str, CELL_TITLE);} else {add_table_cell(&ret, str, CELL_NORMAL);} /* old and new versions */ pm_asprintf(&str, "%s",-- 1.8.5.2
In extended table view, packages which are not explicitly installed are displayed in grey. This helps understanding why packages are updated.
This helps the package managment workflow. During update, we can quickly have a look at why packages are updated and easilly track and remove the explicit packages which are not longer required. During remove, it shows all the explicit packages which are also removed by a cascade removal. During install, it provides a feedback on how your action will affect the database.
This patch created a new colstr setting and associate it with BOLDBLACK (i.e. grey).
Signed-off-by: Guillaume Bouchard guillaum.bouchard@gmail.com --- src/pacman/conf.c | 1 + src/pacman/conf.h | 1 + src/pacman/util.c | 13 ++++++++++--- 3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 5450f3b..785061b 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -76,6 +76,7 @@ void enable_colors(int colors) colstr->warn = BOLDYELLOW; colstr->err = BOLDRED; colstr->nocolor = NOCOLOR; + colstr->depend = BOLDBLACK; } }
diff --git a/src/pacman/conf.h b/src/pacman/conf.h index 9faf5de..2edbe16 100644 --- a/src/pacman/conf.h +++ b/src/pacman/conf.h @@ -32,6 +32,7 @@ typedef struct __colstr_t { const char *warn; const char *err; const char *nocolor; + const char *depend; } colstr_t;
typedef struct __config_t { diff --git a/src/pacman/util.c b/src/pacman/util.c index 58b0cec..7cbbd33 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -57,7 +57,8 @@ enum { CELL_NORMAL = 0, CELL_TITLE = (1 << 0), CELL_RIGHT_ALIGN = (1 << 1), - CELL_FREE = (1 << 3) + CELL_FREE = (1 << 3), + CELL_DEPEND = (1 << 4) };
int trans_init(alpm_transflag_t flags, int check_valid) @@ -488,7 +489,9 @@ static void table_print_line(const alpm_list_t *line, short col_padding,
if(cell->mode & CELL_TITLE) { printf("%s%*s%s", config->colstr.title, cell_width, str, config->colstr.nocolor); - } else { + } else if(cell->mode & CELL_DEPEND) { + printf("%s%*s%s", config->colstr.depend, cell_width, str, config->colstr.nocolor); + } else { printf("%*s", cell_width, str); } need_padding = 1; @@ -808,7 +811,11 @@ static alpm_list_t *create_verbose_row(pm_target_t *target) } else { pm_asprintf(&str, "%s", alpm_pkg_get_name(target->remove)); } - add_table_cell(&ret, str, CELL_NORMAL); + if(alpm_pkg_get_reason(target->remove ? target->remove : target->install) == ALPM_PKG_REASON_DEPEND) { + add_table_cell(&ret, str, CELL_DEPEND); + } else { + add_table_cell(&ret, str, CELL_NORMAL); + }
/* old and new versions */ pm_asprintf(&str, "%s",
Any feedbacks on that patch ? Must I change something ?
On Fri, Jan 24, 2014 at 5:22 PM, Guillaume Bouchard guillaum.bouchard@gmail.com wrote:
In extended table view, packages which are not explicitly installed are displayed in grey. This helps understanding why packages are updated.
This helps the package managment workflow. During update, we can quickly have a look at why packages are updated and easilly track and remove the explicit packages which are not longer required. During remove, it shows all the explicit packages which are also removed by a cascade removal. During install, it provides a feedback on how your action will affect the database.
This patch created a new colstr setting and associate it with BOLDBLACK (i.e. grey).
Signed-off-by: Guillaume Bouchard guillaum.bouchard@gmail.com
src/pacman/conf.c | 1 + src/pacman/conf.h | 1 + src/pacman/util.c | 13 ++++++++++--- 3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 5450f3b..785061b 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -76,6 +76,7 @@ void enable_colors(int colors) colstr->warn = BOLDYELLOW; colstr->err = BOLDRED; colstr->nocolor = NOCOLOR;
colstr->depend = BOLDBLACK; }}
diff --git a/src/pacman/conf.h b/src/pacman/conf.h index 9faf5de..2edbe16 100644 --- a/src/pacman/conf.h +++ b/src/pacman/conf.h @@ -32,6 +32,7 @@ typedef struct __colstr_t { const char *warn; const char *err; const char *nocolor;
const char *depend;} colstr_t;
typedef struct __config_t { diff --git a/src/pacman/util.c b/src/pacman/util.c index 58b0cec..7cbbd33 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -57,7 +57,8 @@ enum { CELL_NORMAL = 0, CELL_TITLE = (1 << 0), CELL_RIGHT_ALIGN = (1 << 1),
CELL_FREE = (1 << 3)
CELL_FREE = (1 << 3),CELL_DEPEND = (1 << 4)};
int trans_init(alpm_transflag_t flags, int check_valid) @@ -488,7 +489,9 @@ static void table_print_line(const alpm_list_t *line, short col_padding,
if(cell->mode & CELL_TITLE) { printf("%s%*s%s", config->colstr.title, cell_width, str, config->colstr.nocolor);
} else {
} else if(cell->mode & CELL_DEPEND) {printf("%s%*s%s", config->colstr.depend, cell_width, str, config->colstr.nocolor);} else { printf("%*s", cell_width, str); } need_padding = 1;@@ -808,7 +811,11 @@ static alpm_list_t *create_verbose_row(pm_target_t *target) } else { pm_asprintf(&str, "%s", alpm_pkg_get_name(target->remove)); }
add_table_cell(&ret, str, CELL_NORMAL);
if(alpm_pkg_get_reason(target->remove ? target->remove : target->install) == ALPM_PKG_REASON_DEPEND) {add_table_cell(&ret, str, CELL_DEPEND);} else {add_table_cell(&ret, str, CELL_NORMAL);} /* old and new versions */ pm_asprintf(&str, "%s",-- 1.8.5.2
On 01/02/14 21:51, Guillaume Bouchard wrote:
Any feedbacks on that patch ? Must I change something ?
I have not looked at it yet. Perhaps someone who uses the verbose table listing wants to review...
Allan
guillaum.bouchard@gmail.com writes:
In extended table view, packages which are not explicitly installed are displayed in grey. This helps understanding why packages are updated.
This helps the package managment workflow. During update, we can quickly have a look at why packages are updated and easilly track and remove the explicit packages which are not longer required. During remove, it shows all the explicit packages which are also removed by a cascade removal. During install, it provides a feedback on how your action will affect the database.
When I tested this patch, it only seemed to work for adding and removing packages, there was no difference while performing upgrades. It looks like this is because the install reason for the upgraded package doesn't get set until commit_single_pkg(), which only runs after the user has confirmed the upgrade. Adding the line below makes the coloring work for upgrades as well.
Also, the patch no longer applies cleanly because of commit 3f34e09.
diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c index f1add24..5ecf6ea 100644 --- a/lib/libalpm/sync.c +++ b/lib/libalpm/sync.c @@ -238,6 +238,7 @@ int SYMEXPORT alpm_sync_sysupgrade(alpm_handle_t *handle, int enable_downgrade) alpm_pkg_t *spkg = _alpm_db_get_pkgfromcache(sdb, lpkg->name); if(spkg) { if(check_literal(handle, lpkg, spkg, enable_downgrade)) { + spkg->reason = alpm_pkg_get_reason(lpkg); trans->add = alpm_list_add(trans->add, spkg); } /* jump to next local package */
This patch created a new colstr setting and associate it with BOLDBLACK (i.e. grey).
Signed-off-by: Guillaume Bouchard guillaum.bouchard@gmail.com
src/pacman/conf.c | 1 + src/pacman/conf.h | 1 + src/pacman/util.c | 13 ++++++++++--- 3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 5450f3b..785061b 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -76,6 +76,7 @@ void enable_colors(int colors) colstr->warn = BOLDYELLOW; colstr->err = BOLDRED; colstr->nocolor = NOCOLOR;
colstr->depend = BOLDBLACK;}
diff --git a/src/pacman/conf.h b/src/pacman/conf.h index 9faf5de..2edbe16 100644 --- a/src/pacman/conf.h +++ b/src/pacman/conf.h @@ -32,6 +32,7 @@ typedef struct __colstr_t { const char *warn; const char *err; const char *nocolor;
- const char *depend;
} colstr_t;
typedef struct __config_t { diff --git a/src/pacman/util.c b/src/pacman/util.c index 58b0cec..7cbbd33 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -57,7 +57,8 @@ enum { CELL_NORMAL = 0, CELL_TITLE = (1 << 0), CELL_RIGHT_ALIGN = (1 << 1),
- CELL_FREE = (1 << 3)
- CELL_FREE = (1 << 3),
- CELL_DEPEND = (1 << 4)
};
int trans_init(alpm_transflag_t flags, int check_valid) @@ -488,7 +489,9 @@ static void table_print_line(const alpm_list_t *line, short col_padding,
if(cell->mode & CELL_TITLE) { printf("%s%*s%s", config->colstr.title, cell_width, str, config->colstr.nocolor);
} else {
} else if(cell->mode & CELL_DEPEND) {printf("%s%*s%s", config->colstr.depend, cell_width, str, config->colstr.nocolor);} else { printf("%*s", cell_width, str);@@ -808,7 +811,11 @@ static alpm_list_t *create_verbose_row(pm_target_t *target) } else { pm_asprintf(&str, "%s", alpm_pkg_get_name(target->remove)); }
- add_table_cell(&ret, str, CELL_NORMAL);
- if(alpm_pkg_get_reason(target->remove ? target->remove : target->install) == ALPM_PKG_REASON_DEPEND) {
This is mainly a style thing but there is an if-else right before this line that checks for target->remove and target->install. I think folding the install reason check into the previous if-else flows better but there is no logical difference.
add_table_cell(&ret, str, CELL_DEPEND);} else {
add_table_cell(&ret, str, CELL_NORMAL);}
/* old and new versions */ pm_asprintf(&str, "%s",
Cheers, Chirantan
-- Sent with my mu4e
Hi,
On Sat, Feb 1, 2014 at 9:27 PM, Chirantan Ekbote chirantan.ekbote@gmail.com wrote:
When I tested this patch, it only seemed to work for adding and removing packages, there was no difference while performing upgrades. It looks like this is because the install reason for the upgraded package doesn't get set until commit_single_pkg(), which only runs after the user has confirmed the upgrade. Adding the line below makes the coloring work for upgrades as well.
From my tests, my changes works even during update.
I'm using alpm_pkg_get_reason of target->remove for upgrade and removal (because it is the obvious choice for removal, and in case of upgrade, I see that target->remove is correctly tagged).
Also, the patch no longer applies cleanly because of commit 3f34e09.
Indeed, I'll mail an updated patch now.
In my first patch, I proposed putting in bold the name of explicitly installed packages. This patch put in grey the name of "dependencies". Which one should we keep ?
In extended table view, packages which are not explicitly installed are displayed in grey. This helps understanding why packages are updated.
This helps the package managment workflow. During update, we can quickly have a look at why packages are updated and easilly track and remove the explicit packages which are not longer required. During remove, it shows all the explicit packages which are also removed by a cascade removal. During install, it provides a feedback on how your action will affect the database.
This patch created a new colstr setting and associate it with BOLDBLACK (i.e. grey).
Signed-off-by: Guillaume Bouchard guillaum.bouchard@gmail.com --- src/pacman/conf.c | 1 + src/pacman/conf.h | 1 + src/pacman/util.c | 13 ++++++++++--- 3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 4b7ec05..243203f 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -76,6 +76,7 @@ void enable_colors(int colors) colstr->warn = BOLDYELLOW; colstr->err = BOLDRED; colstr->nocolor = NOCOLOR; + colstr->depend = BOLDBLACK; } }
diff --git a/src/pacman/conf.h b/src/pacman/conf.h index e8cac50..4af5eeb 100644 --- a/src/pacman/conf.h +++ b/src/pacman/conf.h @@ -32,6 +32,7 @@ typedef struct __colstr_t { const char *warn; const char *err; const char *nocolor; + const char *depend; } colstr_t;
typedef struct __config_t { diff --git a/src/pacman/util.c b/src/pacman/util.c index cbe371d..699d347 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -57,7 +57,8 @@ enum { CELL_NORMAL = 0, CELL_TITLE = (1 << 0), CELL_RIGHT_ALIGN = (1 << 1), - CELL_FREE = (1 << 3) + CELL_FREE = (1 << 3), + CELL_DEPEND = (1 << 4) };
int trans_init(alpm_transflag_t flags, int check_valid) @@ -488,7 +489,9 @@ static void table_print_line(const alpm_list_t *line, short col_padding,
if(cell->mode & CELL_TITLE) { printf("%s%*s%s", config->colstr.title, cell_width, str, config->colstr.nocolor); - } else { + } else if(cell->mode & CELL_DEPEND) { + printf("%s%*s%s", config->colstr.depend, cell_width, str, config->colstr.nocolor); + } else { printf("%*s", cell_width, str); } need_padding = 1; @@ -808,7 +811,11 @@ static alpm_list_t *create_verbose_row(pm_target_t *target) } else { pm_asprintf(&str, "%s", alpm_pkg_get_name(target->remove)); } - add_table_cell(&ret, str, CELL_NORMAL | CELL_FREE); + if(alpm_pkg_get_reason(target->remove ? target->remove : target->install) == ALPM_PKG_REASON_DEPEND) { + add_table_cell(&ret, str, CELL_DEPEND | CELL_FREE); + } else { + add_table_cell(&ret, str, CELL_NORMAL | CELL_FREE); + }
/* old and new versions */ pm_asprintf(&str, "%s",
On 02/02/14 07:41, Guillaume Bouchard wrote:
In extended table view, packages which are not explicitly installed are displayed in grey. This helps understanding why packages are updated.
This helps the package managment workflow. During update, we can quickly have a look at why packages are updated and easilly track and remove the explicit packages which are not longer required. During remove, it shows all the explicit packages which are also removed by a cascade removal. During install, it provides a feedback on how your action will affect the database.
This patch created a new colstr setting and associate it with BOLDBLACK (i.e. grey).
That colour cases the dependencies to stand out more on a terminal with a white background. I'd say bold would be better...
However, the colour coding really is unclear. How do people come into the knowledge of what it means? For example, during an update I might think that a new package being pulled in as a dependency so it is highlighted. Or is it entirely obvious and I am thinking too hard?
Allan
Signed-off-by: Guillaume Bouchard guillaum.bouchard@gmail.com
src/pacman/conf.c | 1 + src/pacman/conf.h | 1 + src/pacman/util.c | 13 ++++++++++--- 3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 4b7ec05..243203f 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -76,6 +76,7 @@ void enable_colors(int colors) colstr->warn = BOLDYELLOW; colstr->err = BOLDRED; colstr->nocolor = NOCOLOR;
colstr->depend = BOLDBLACK;}
diff --git a/src/pacman/conf.h b/src/pacman/conf.h index e8cac50..4af5eeb 100644 --- a/src/pacman/conf.h +++ b/src/pacman/conf.h @@ -32,6 +32,7 @@ typedef struct __colstr_t { const char *warn; const char *err; const char *nocolor;
- const char *depend;
} colstr_t;
typedef struct __config_t { diff --git a/src/pacman/util.c b/src/pacman/util.c index cbe371d..699d347 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -57,7 +57,8 @@ enum { CELL_NORMAL = 0, CELL_TITLE = (1 << 0), CELL_RIGHT_ALIGN = (1 << 1),
- CELL_FREE = (1 << 3)
- CELL_FREE = (1 << 3),
- CELL_DEPEND = (1 << 4)
};
int trans_init(alpm_transflag_t flags, int check_valid) @@ -488,7 +489,9 @@ static void table_print_line(const alpm_list_t *line, short col_padding,
if(cell->mode & CELL_TITLE) { printf("%s%*s%s", config->colstr.title, cell_width, str, config->colstr.nocolor);
} else {
} else if(cell->mode & CELL_DEPEND) {printf("%s%*s%s", config->colstr.depend, cell_width, str, config->colstr.nocolor);} else { printf("%*s", cell_width, str);@@ -808,7 +811,11 @@ static alpm_list_t *create_verbose_row(pm_target_t *target) } else { pm_asprintf(&str, "%s", alpm_pkg_get_name(target->remove)); }
- add_table_cell(&ret, str, CELL_NORMAL | CELL_FREE);
if(alpm_pkg_get_reason(target->remove ? target->remove : target->install) == ALPM_PKG_REASON_DEPEND) {
add_table_cell(&ret, str, CELL_DEPEND | CELL_FREE);} else {
add_table_cell(&ret, str, CELL_NORMAL | CELL_FREE);}
/* old and new versions */ pm_asprintf(&str, "%s",
That colour cases the dependencies to stand out more on a terminal with a white background. I'd say bold would be better...
;) I agree on that part. I guess the best idea must be to create a color class for depend and for explicit so that changing it latter may be easier.
However, the colour coding really is unclear. How do people come into the knowledge of what it means? For example, during an update I might think that a new package being pulled in as a dependency so it is highlighted. Or is it entirely obvious and I am thinking too hard?
You are right. Perhaps a caption, like:
--------------------------------------------------------------------------- $ sudo pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts...
Packages (21): **(Explict packages appears in bold)**
Name Old Version New Version Net Change Download Size
...
Total Download Size: 154.72 MiB Total Installed Size: 491.30 MiB Net Upgrade Size: -1.28 MiB
:: Proceed with installation? [Y/n] -----------------------------------------------------------------------------------------
?
(I had never though a *so simple* hack would generate so much discussion ;)
On Sun, Feb 2, 2014 at 8:45 AM, Guillaume Bouchard guillaume.bouchard@liris.cnrs.fr wrote:
That colour cases the dependencies to stand out more on a terminal with a white background. I'd say bold would be better...
;) I agree on that part. I guess the best idea must be to create a color class for depend and for explicit so that changing it latter may be easier.
However, the colour coding really is unclear. How do people come into the knowledge of what it means? For example, during an update I might think that a new package being pulled in as a dependency so it is highlighted. Or is it entirely obvious and I am thinking too hard?
I agree that this would not be obvious to users.
You are right. Perhaps a caption, like:
$ sudo pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts...
Packages (21): **(Explict packages appears in bold)**
Name Old Version New Version Net Change Download Size
...
Total Download Size: 154.72 MiB Total Installed Size: 491.30 MiB Net Upgrade Size: -1.28 MiB
:: Proceed with installation? [Y/n]
?
(I had never though a *so simple* hack would generate so much discussion ;)
-- Guillaume
I don't like the idea of a caption that says something like "explicitly installed packages appear in bold".
An extra column would be better than a caption, but I don't know how everyone feels about that...
I see three ways of doing this with a column: 1.) have a column title of "Explicitly Installed?" with a "yes" or "no" label for each package, optionally coloring the "yes" or "no" text for easy reading 2.) like the first way, but put an asterisk if the package is explicitly installed and leave it blank if the package is a dependency 3.) have a column title of "Installed..." with labels of "explicitly" or "as a dependency"
Of those three, I think I prefer the second method.
Jason
On 03/02/14 15:34, Jason St. John wrote:
On Sun, Feb 2, 2014 at 8:45 AM, Guillaume Bouchard guillaume.bouchard@liris.cnrs.fr wrote:
That colour cases the dependencies to stand out more on a terminal with a white background. I'd say bold would be better...
;) I agree on that part. I guess the best idea must be to create a color class for depend and for explicit so that changing it latter may be easier.
However, the colour coding really is unclear. How do people come into the knowledge of what it means? For example, during an update I might think that a new package being pulled in as a dependency so it is highlighted. Or is it entirely obvious and I am thinking too hard?
I agree that this would not be obvious to users.
You are right. Perhaps a caption, like:
$ sudo pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts...
Packages (21): **(Explict packages appears in bold)**
Name Old Version New Version Net Change Download Size
...
Total Download Size: 154.72 MiB Total Installed Size: 491.30 MiB Net Upgrade Size: -1.28 MiB
:: Proceed with installation? [Y/n]
?
(I had never though a *so simple* hack would generate so much discussion ;)
-- Guillaume
I don't like the idea of a caption that says something like "explicitly installed packages appear in bold".
An extra column would be better than a caption, but I don't know how everyone feels about that...
I see three ways of doing this with a column: 1.) have a column title of "Explicitly Installed?" with a "yes" or "no" label for each package, optionally coloring the "yes" or "no" text for easy reading 2.) like the first way, but put an asterisk if the package is explicitly installed and leave it blank if the package is a dependency 3.) have a column title of "Installed..." with labels of "explicitly" or "as a dependency"
Of those three, I think I prefer the second method.
I'm not sure there is enough room for another column - especially not with a title that long.
Allan
On Mon, Feb 3, 2014 at 12:45 AM, Allan McRae allan@archlinux.org wrote:
On 03/02/14 15:34, Jason St. John wrote:
On Sun, Feb 2, 2014 at 8:45 AM, Guillaume Bouchard guillaume.bouchard@liris.cnrs.fr wrote:
That colour cases the dependencies to stand out more on a terminal with a white background. I'd say bold would be better...
;) I agree on that part. I guess the best idea must be to create a color class for depend and for explicit so that changing it latter may be easier.
However, the colour coding really is unclear. How do people come into the knowledge of what it means? For example, during an update I might think that a new package being pulled in as a dependency so it is highlighted. Or is it entirely obvious and I am thinking too hard?
I agree that this would not be obvious to users.
You are right. Perhaps a caption, like:
$ sudo pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts...
Packages (21): **(Explict packages appears in bold)**
Name Old Version New Version Net Change Download Size
...
Total Download Size: 154.72 MiB Total Installed Size: 491.30 MiB Net Upgrade Size: -1.28 MiB
:: Proceed with installation? [Y/n]
?
(I had never though a *so simple* hack would generate so much discussion ;)
-- Guillaume
I don't like the idea of a caption that says something like "explicitly installed packages appear in bold".
An extra column would be better than a caption, but I don't know how everyone feels about that...
I see three ways of doing this with a column: 1.) have a column title of "Explicitly Installed?" with a "yes" or "no" label for each package, optionally coloring the "yes" or "no" text for easy reading 2.) like the first way, but put an asterisk if the package is explicitly installed and leave it blank if the package is a dependency 3.) have a column title of "Installed..." with labels of "explicitly" or "as a dependency"
Of those three, I think I prefer the second method.
I'm not sure there is enough room for another column - especially not with a title that long.
Allan
Currently, the width of the verbose package list is 66 columns (checked with an update of "extra/firefox" and "community/lz4"). Each column uses two space characters between titles. If we, instead, make the title be "Dependency?" and we reverse the use of asterisks, the new width would be 79 columns (66 + 2 + 11). If we're targeting a max width of 80 columns, this would be just under the limit. For packages with long names and/or are in a repository with a long name (e.g. community), it would hit the max width pretty easily.
If this increase in width is too close to the maximum desired width, we will have to scrap the idea of using an additional column, and we'll have to think of another way to display this information.
Jason
On 05/02/14 10:34, Jason St. John wrote:
On Mon, Feb 3, 2014 at 12:45 AM, Allan McRae allan@archlinux.org wrote:
On 03/02/14 15:34, Jason St. John wrote:
On Sun, Feb 2, 2014 at 8:45 AM, Guillaume Bouchard guillaume.bouchard@liris.cnrs.fr wrote:
That colour cases the dependencies to stand out more on a terminal with a white background. I'd say bold would be better...
;) I agree on that part. I guess the best idea must be to create a color class for depend and for explicit so that changing it latter may be easier.
However, the colour coding really is unclear. How do people come into the knowledge of what it means? For example, during an update I might think that a new package being pulled in as a dependency so it is highlighted. Or is it entirely obvious and I am thinking too hard?
I agree that this would not be obvious to users.
You are right. Perhaps a caption, like:
$ sudo pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts...
Packages (21): **(Explict packages appears in bold)**
Name Old Version New Version Net Change Download Size
...
Total Download Size: 154.72 MiB Total Installed Size: 491.30 MiB Net Upgrade Size: -1.28 MiB
:: Proceed with installation? [Y/n]
?
(I had never though a *so simple* hack would generate so much discussion ;)
-- Guillaume
I don't like the idea of a caption that says something like "explicitly installed packages appear in bold".
An extra column would be better than a caption, but I don't know how everyone feels about that...
I see three ways of doing this with a column: 1.) have a column title of "Explicitly Installed?" with a "yes" or "no" label for each package, optionally coloring the "yes" or "no" text for easy reading 2.) like the first way, but put an asterisk if the package is explicitly installed and leave it blank if the package is a dependency 3.) have a column title of "Installed..." with labels of "explicitly" or "as a dependency"
Of those three, I think I prefer the second method.
I'm not sure there is enough room for another column - especially not with a title that long.
Allan
Currently, the width of the verbose package list is 66 columns (checked with an update of "extra/firefox" and "community/lz4"). Each column uses two space characters between titles. If we, instead, make the title be "Dependency?" and we reverse the use of asterisks, the new width would be 79 columns (66 + 2 + 11). If we're targeting a max width of 80 columns, this would be just under the limit. For packages with long names and/or are in a repository with a long name (e.g. community), it would hit the max width pretty easily.
If this increase in width is too close to the maximum desired width, we will have to scrap the idea of using an additional column, and we'll have to think of another way to display this information.
It is too long.
Allan
1.) have a column title of "Explicitly Installed?" with a "yes" or "no" label for each package, optionally coloring the "yes" or "no" text for easy reading 2.) like the first way, but put an asterisk if the package is explicitly installed and leave it blank if the package is a dependency 3.) have a column title of "Installed..." with labels of "explicitly" or "as a dependency"
Of those three, I think I prefer the second method.
I like the second method, but it is still not really explicit for users.
I'll wait for a few other feedbacks and I'll update the patch to add an asterix after the package name.
On Sat, Feb 1, 2014 at 4:40 PM, Guillaume Bouchard guillaum.bouchard@gmail.com wrote:
Hi,
On Sat, Feb 1, 2014 at 9:27 PM, Chirantan Ekbote chirantan.ekbote@gmail.com wrote:
When I tested this patch, it only seemed to work for adding and removing packages, there was no difference while performing upgrades. It looks like this is because the install reason for the upgraded package doesn't get set until commit_single_pkg(), which only runs after the user has confirmed the upgrade. Adding the line below makes the coloring work for upgrades as well.
From my tests, my changes works even during update.
I'm using alpm_pkg_get_reason of target->remove for upgrade and removal (because it is the obvious choice for removal, and in case of upgrade, I see that target->remove is correctly tagged).
Also, the patch no longer applies cleanly because of commit 3f34e09.
Indeed, I'll mail an updated patch now.
In my first patch, I proposed putting in bold the name of explicitly installed packages. This patch put in grey the name of "dependencies". Which one should we keep ?
Of the two options, I would prefer the dependencies to be shown in grey instead of having explicitly installed packages typeset in bold. I don't feel too strongly about this though, so I won't complain if everyone else prefers bold.
Jason
Of the two options, I would prefer the dependencies to be shown in grey instead of having explicitly installed packages typeset in bold. I don't feel too strongly about this though, so I won't complain if everyone else prefers bold.
There is a second option. Instead of just flaging deps OR explicit and associating a color with both, we can flag both and associate a color with both, and let this color be changed by "configuration" (i.e., the line in conf.c/enable_color) so everybody will be happy...
On Fri, Jan 24, 2014 at 4:24 PM, Jerome Leclanche adys.wh@gmail.com wrote:
On Fri, Jan 24, 2014 at 2:17 PM, Guillaume Bouchard guillaum.bouchard@gmail.com wrote:
In extended table view, packages which are explicitly installed are displayed as CELL_TITLE (i.e. in bold). This helps understanding why packages are updated.
This helps the package managment workflow. During update, we can quickly have a look at why packages are updated and easilly track and remove the explicit packages which are not longer required. During remove, it shows all the explicit packages which are also removed by a cascade removal. During install, it provides a feedback on how your action will affect the database.
2¢ for the bikeshed: have you tried putting non-explicitly installed packages in grey instead? It might make more sense.
Patch sent (However, I may have failed the "Message-Id" because it does not appears as a child of this discussion.
I'm not really convinced with the "Grey" results. And for the grey I was forced to add a new colstr category which linked to BOLDBLACK.
pacman-dev@lists.archlinux.org