Bug 212940 - RFE: Pirut/Pup -- Information in Progress Window
RFE: Pirut/Pup -- Information in Progress Window
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pirut (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-30 03:50 EST by Gian Paolo Mureddu
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-09 16:07:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gian Paolo Mureddu 2006-10-30 03:50:36 EST
Full summary:

Make Pup and Pirut show more information to the user in the progress window.

Rationale:

Pirut and Pup are probably key to the desktop in Fedora Core, because they're
the applications responsible for delivering system updates as well as the means
to get new software installed into the system from the Internet and the various
repositories. I think that it will be in the best interest of the users to be a
bit more verbose in the progress windows of each programs. For example the
command-line interface of YUM is quite verbose about a series of things, like
size of individual packages, total size for download of the selected packages
and last but definitely not least, the time remaining for the currently
downloading file. Pup and Pirut could immensely benefit from showing information
such as this, and even some advanced controls within the progress window.
Consider the following:

* Size of the individual files. In the case of Pup that also means to have a
number at the very bottom of the window stating the total size of the download.
This can help quite a bit for people who need to plan their updates and only get
the most critical ones and then download the bigger ones. For instance state the
size of a new kernel package and that of OpenOffice.org-core, so the users can
get the most critical first (kernel) and the let the bigger one
(OpenOffice.org-core) for a later, whey they have more time. The same goes for
Pirut, to show the size of the files when they are being selected. Also make it
so that in the confirmation window of Pirut, the total size for the transaction
will be displayed. In both cases a total ETA (at a certain network speed) would
also be desirable.

* Remaining time for the currently downloading file. At the very least, just
beside the name of file currently being downloaded, an ETA could be shown, plus
the size of the file.

* Have an advanced drop-down hidden menu (like the one for file type in GIMP's
Open File menu or OpenOffice.org's) for other actions and information. Such
actions and information would be: current mirror, actual network speed of the
file transfer in kb|mb/sec and a button to switch mirrors if the transfer is too
slow (even make it so it is only lit [available] if the file transfer is bellow
a certain threshold); also information of the currently used yum plug-ins would
be desirable.

Such enhancements will render the applications much more useful. Currently they
do their job just fine, but feel kind of rough around the edges. The proposed
enhancements follow the paradigm of the GNOME desktop in that they wold add more
information and not clutter the interface, leaving it clean, but more useful.
Comment 1 Jeremy Katz 2007-04-09 16:07:39 EDT
The size of the package shouldn't be the driving factor (and longer term, should
be even less so as things like presto are able to be well integrated into the
distribution).  Similarly, estimating download times is not something that can
be done with a high degree of reliability.
Comment 2 Gian Paolo Mureddu 2007-04-09 21:43:37 EDT
It is a major piece of information, especially for countries where broad band
penetration has been slow, and even a 200-300 Mb update could take hours to
perform. In my country the state of things is such that the lowest "broad band"
access is of about 128kbps, and the mean broad band access is of about 512kbps.
Compare this to other countries where 3 or even 8 mbps are common place. In such
conditions a 200-300 Mb update is a snap, while for countries such as Mexico and
other Latinamerican countries it may take quite a while.

Also these enchancements could desperately benefit Anaconda... Though this would
be a totally different RFE, Anaconda could also immensely benefit from being a
bit more verbose and leave the user less in the dark about the estimated time a
download/install will take, especially if the mirrors are selected during
installation... where currently (FC6) it doesn't even display whether a package
is being downloaded or installed from local media.

Maybe Fedora is not the ideal distribution for nations such as ours, but
personally I love Fedora, and also think that these enchacements benefit us all.

Note You need to log in before you can comment on or make changes to this bug.