Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#25817 - TotalDownload-like switch for checking package integrity

Attached to Project: Pacman
Opened by Karol Błażewicz (karol) - Monday, 29 August 2011, 19:55 GMT
Last edited by Dan McGee (toofishes) - Tuesday, 22 November 2011, 04:39 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 3.5.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Today I was installing flightgear and found a problem I already reported on a forum thread [1]: the package shows wrong uncompressed size (for 32-bit only).

[karol@black ~]$ pacman -S flightgear
resolving dependencies...
looking for inter-conflicts...

Targets (17): mesa-7.11-1 [0,27 MB] freeglut-2.6.0-1 [0,19 MB] jasper-1.900.1-6 [0,18 MB]
xine-lib-1.1.19-3 [2,70 MB] pth-2.0.7-3 [0,09 MB]
openscenegraph-3.0.1-1 [5,44 MB] openal-1.13-2 [0,10 MB]
freealut-1.1.0-3 [0,03 MB] plib-1.8.5-2 [0,54 MB] simgear-2.4.0-1 [1,03 MB]
neon-0.29.6-2 [0,17 MB] apr-1.4.5-1 [0,25 MB] unixodbc-2.3.0-1 [0,19 MB]
apr-util-1.3.12-2 [0,16 MB] subversion-1.6.17-6 [4,02 MB]
flightgear-data-2.4.0-1 [2048,00 MB] flightgear-2.4.0-1 [2,46 MB]

Total Download Size: 2065,55 MB
Total Installed Size: 2135,52 MB

As you can see, one package - flightgear-data - is pretty damn big (actually, it's even bigger) and it will take the most time downloading etc. When we get to checksumming this huge package, 15 out of 17 packages have already been processed. Unfortunately, the progress bar seems to be a graphical representation of 15/17 fraction:

(15/17) checking package integrity [#############################---] 88%

The progress bar and percentage will be stuck at 88% for a loooong time.
It would be cool if it could instead represent the size as TotalDownload switch does for downloading.

[1] https://bbs.archlinux.org/viewtopic.php? pid=983449#p983449
This task depends upon

Closed by  Dan McGee (toofishes)
Tuesday, 22 November 2011, 04:39 GMT
Reason for closing:  Deferred
Additional comments about closing:  This is mostly taken care of by the two progress bars as well as the new scaling by package size in the progress meter.
Comment by Dan McGee (toofishes) - Monday, 29 August 2011, 20:38 GMT
I will not accept any such TotalDownload switch; I already find that a total hack that I'd like to kill in its current form.

We have a lot of things that could be better represented with two progress bars instead of one; however consoles are tricky things and doing this sans-ncurses might be a bit hard to do.

I think the most prudent short-term solution is a simple one- rather than doing a simple 15/17 (current/total packages), add the compressed size of all packages and use that to calculate a percentage. The updates won't happen more frequently, but the progress bar won't be as misleading.

P.S. you don't need to quote the pacman manpage (that we wrote!) on a feature when filing a bug with us. :) It really just adds clutter, and I'm going to edit that out...
Comment by Dan McGee (toofishes) - Thursday, 06 October 2011, 15:07 GMT
Note that in 4.0, we've split the progress bar in two to reflect reality- one for 'checking package integrity', and one for 'loading package files'.
Comment by Karol Błażewicz (karol) - Thursday, 06 October 2011, 17:34 GMT
Oh yes, I've seen this and I like it a lot :-)

Loading...