You are not logged in.
Pages: 1
Topic closed
This is a gentle request, which I can easily do without, and originates from my Debian background.
Would it be possible for pacman to give a total MB figure and/or a total time remaining figure, when it's doing upgrades/installs? The individual figures per package are great, but I like the way apt gives me the total upfront, so I know how long the whole thing is going to take.
Offline
i can second this - would be a really great feature, yes!
(i never missed it, because i never had it as idea - in debian i never read the output of apt-get :oops: , but in archlinux, you do much more often -Suy the system and use more bandwidth than debian.stable)
The impossible missions are the only ones which succeed.
Offline
I'm confused does pacman not do that already :?
Mr Green
Offline
No, not for the whole upgrade, only for the current package it's downloading.
It's trivial to implement if the pkgbuild knows how big the downloads are, but currently it knows that only via ftp when actually downloading. It's possible to connect to all servers first and check out the sizes, and then download the seperate packages, but that would complicate Pacman and is some work to implement.
I'd like to know the package size before I start downloading (with pacman -Si), so I would implement it the first way.
Offline
Okay, this feature is on the list.
Offline
great
The impossible missions are the only ones which succeed.
Offline
you do realize that features such as this are usually not that accurate?
that being said it would be nice.
AKA uknowme
I am not your friend
Offline
The inaccuracy comes from the fact that the donwload speed isn't known beforehand, but adding an ETA with the current download rate can be still useful and be as accurate as it's name.
I don't know how Judd wants to implement it, with an extra database entry with size info, or the FTP trick, or something else, but if using FTP then there's the problem that not all FTP servers know the size of the file (most times it doesn't seem to, at least the mirror I use not).
It also me be a bit tricky to let it work nicely when using external downloaders like wget. If the output file is known, or when the program writes the file to stdout which Pacman redirected then it's doable to have live ETA, but otherwise you can only give the ETA between two downloads.
Offline
I picture a total-file-size implementation looking something like this:
- modify gensync to store PACKAGESIZE in the db.
- modify pacman to read all the upgrading package's PACKAGESIZE and add it together.
The ETA calculation is easy as well using the internal downloader. I can't see the XferCommand being used in that way.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
ok - observations - doesn't wget do the size of the package anyway? or just not in collaboration with Pacman? it certainly does in makepkg, doesn't it?
second, who thinks that the current ETA bit on the end of a pacman progress line is useful?! it just seems to jump about randomly and tends to read that it still needs 2 mins or so when it has finished! ![]()
Offline
i don't need to know the ETA, but the size to be downloaded - everyone can say from experience, how long it takes with his/her connection to download e.g. 10mb from serverXY
The impossible missions are the only ones which succeed.
Offline
i concur
Offline
I agree... this feature would be great (as well as another one I have asked about before: http://bbs.archlinux.org/viewtopic.php?t=6039 ).
ETA is not really necessary, just the total size.
And where it should be implemented: When Pacman shows "Targets" and asks you to "Proceed?", it could easily tell you the total size... So the poor dial uppers can decide whether to do it at their comp or somewhere else :-)
I personally would <b>not</b> need a "total progress" bar. Just the size in advance.
Looking forward to it, Frank
Offline
Targets: apache-2.0.51-1 freeciv-1.14.2-1 nss-nspr-3.9-1 gaim-1.0.0-2
hpijs-1.6.2-1 k3b-0.11.16-1 kdeartwork-3.3.0-2 libsigc++2.0-2.0.3-2
shared-mime-info-0.15-1 strace-4.5.7-1 subversion-1.0.7-1 tetex-2.0.2-6
whois-4.6.22-1 xine-lib-1rc6a-1 xorg-11R6.8.1-1
Total Package Size: 119.8 MB
Proceed with upgrade? [Y/n] wonderfull!!!! -- thanx the people with ideas, the people who realized it and the users to find it usefull
The impossible missions are the only ones which succeed.
Offline
ETA is very nice to have, sure, it's not 100% accurate, but there's one thing if you have 50 min to download or 1 min. it gives you a ballpark idea.
Correct me if I'm wrong, but if you get ETA per package and you actually download more than one package the ETA per package is very close to useless (why do you need to know when a package finishes to download?), what's relevant is the ETA for all packages. Debian got this right, Arch hasn't yet.
Offline
Edit: this post is many years old. Thing have changed since then. Please read: http://wiki.archlinux.org/index.php/For … Bumping.27
I deleted my answer so you learn to search yourself...
Offline
Pages: 1
Topic closed