Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#43311 - add color highlighting to package lists

Attached to Project: Arch Linux
Opened by Stefan Majewsky (majewsky) - Friday, 02 January 2015, 23:15 GMT
Last edited by Allan McRae (Allan) - Saturday, 03 January 2015, 01:09 GMT
Task Type Feature Request
Category Arch Projects
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I recently found the "VerbosePkgLists" option in pacman.conf, and I like it very much, but here's one addition that I would find very useful.

When both "VerbosePkgLists" and "Color" are enabled, it would be nice if those packages were highlighted that have a major update (i.e. the major version differs). Same for minor updates, but with a weaker highlight. The unhighlighted packages then only have a bugfix release. That would greatly help me digest the package list faster.

Such highlighting could also be useful for the non-verbose package list, although in this case some kind of explanatory text might be needed.
This task depends upon

Closed by  Allan McRae (Allan)
Saturday, 03 January 2015, 01:09 GMT
Reason for closing:  Won't implement
Comment by Karol Błażewicz (karol) - Saturday, 03 January 2015, 00:15 GMT
What do you mean by 'That would greatly help me digest the package list faster.'? You read the package list and do what?
Comment by Stefan Majewsky (majewsky) - Saturday, 03 January 2015, 00:21 GMT
I mean that I can more quickly identify which update in a potentially long list of updates is a major one (and might thus be troublesome).
Comment by Allan McRae (Allan) - Saturday, 03 January 2015, 00:31 GMT
Is gcc-4.2.1 to gcc-4.3.0 a major update or just gcc-4.x to gcc-5.0? Does the same versioning apply to every package?
Comment by Dave Reisner (falconindy) - Saturday, 03 January 2015, 00:39 GMT
What about projects which do not use semver-style versioning? I don't think pacman should be in the business of trying to discern the "severity" of an update based on versioning information alone.
Comment by Stefan Majewsky (majewsky) - Saturday, 03 January 2015, 00:45 GMT
I usually read "4.2.1-3" as "major.minor.bugfix-release", so in my book, a "major upgrade" is one that changes the major version (the first number), and a "minor upgrade" changes the minor version (the second number). A "bugfix upgrade" changes only the bugfix version or the package release.

I'm well aware that determining a "Major upgrade" only from the version number is only best-effort, but frankly, I'm not doing anything else when I read the package version lists manually. The point of this feature request is for me to be able to skip the 80% of updates that are "4.3.8 -> 4.3.9" which I would rate as "very low chance of breakage" anyway.

An example for a simple best-effort algorithm to determine major upgrades (e.g. "4.3.8-1 -> 4.3.9-1" is minor, but "4.3.9-1 -> 4.4.0-1" is major, as is "22-1" -> "23-1"):

if pkgver has more than two numbers:
isMajorUpdate = any number in pkgver changes, except for the last one
else:
isMajorUpdate = true
Comment by Dave Reisner (falconindy) - Saturday, 03 January 2015, 01:00 GMT
systemd 208->209 was a "major" update, but 203->204 was just a bugfix release. All releases between 204 and 208 would be considered "minor" updates. You cannot possibly get this right.

Also, your pseudo-code contradicts your original statement. Your original statement declares that 4.3.0 -> 4.4.0 is a minor update, but your pseudocode says it's a major.

Loading...