Kevin Kofler wrote:
Chris Lumens <clumens <at> redhat.com> writes:
We used to have that, but removed it. The reason is that our estimates
are never going to be very good based on all sorts of things like time
to download packges (in HTTP/FTP cases) and how long it takes to run a
package's pre/post scriptlet.
In fact, in my experience, the estimates have always been complete nonsense
(off by a factor of 2 in either direction or things like that) even for fairly
predictable HDD installs, so IMHO you did the right thing. :-)
Why not just showing the *elapsed* time, instead of the time to
completion? Elapsed is accurate. :-)
I mean, a user can mentally roughly estimate the remaining time using
the elapsed time and the progress bar; but we avoid the "45 minutes,
25 minutes, 55 minutes" effect.
And if the progress bar is completely unreliable as a time-related axis,
why is it there? Only to show that the process is running? A simple
scrolling list of packages as they're installed would be better, then.
BTW, using the size of the packages as input for the progress bar
appears inappropriate to me in recent Fedora versions as the big
part of the elapsed time is taken by install scripts, not by the
file copying.
I tried a simple experiment on my Fedora 8:
$ rpm -qa|wc -l
2458
$ rpm -qa --scripts >/tmp/all_scripts
$ grep -c ldconfig /tmp/all_scripts
1348
$ grep -c gtk-update-icon-cache /tmp/all_scripts
436
$ grep -c update-desktop-database /tmp/all_scripts
165
$ grep -c fc-cache /tmp/all_scripts
144
The installation time, expecially when upgrading (many packages,
more fragmentation) is becoming too long. Executing more than
1000 times something which finds all the libs in the system
can't be totally right. On modern machines the disk cache
helps a lot, so everything becomes CPU bound, and then fast
CPUs also help. At that point the bottleneck becomes the
RPM DB transaction stuff (tons of fsync()?), expecially in the
last phase of the process which seems to take forever.
On older laptops (512MB, slow disk) the cache is ineffective
and the disk goes crazy.
I have no idea how this can be solved, but I still want to raise
this as an issue, it is getting bad.
Best regards.
--
Roberto Ragusa mail at robertoragusa.it
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
