[Bug 410310] Re: update-manager inconsistent with download size
Robert Roth
evfool at gmail.com
Thu Jul 21 11:51:51 UTC 2011
Thanks Manfred, you've got a really good point there, and you've found the root of the problem. Setting to Triaged, and updating the description of the bug according to your highly detailed comment.
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad
** Changed in: update-manager (Ubuntu)
Assignee: (unassigned) => Robert Roth (evfool)
** Changed in: update-manager (Ubuntu)
Status: Incomplete => Confirmed
** Description changed:
Binary package hint: update-manager
There are three places, where the update-manager states the download size of an update:
-For every package itself
-For all packages together
-During download
- All 3 state different sizes of a download. (see attachment)
- This is also the case in Karmic.
+ The first two and the third one differ. (see attachment - the total and the per-package difference has been fixed in the meantime, the difference between update-manager main window and the progress windows still exists)
+
+ When doing an update with update-manager some numbers displayed on screen come from update-manager and some from apt.
+ And now apt is displaying the numbers with decimal kilos (K=1000), and update-manager is displaying the numbers with binary kilos (K=1024). Even if the float problem is solved, this still gives a difference in display of about 4.8% for Megabyte numbers. (see some more details in my comment #9 above and some of the attached pictures).
+
+ Before this bug is set to 'Fix Released' I would like to raise the
+ question if it would make sense to consistently use one and the same
+ factor for kilo/mega representation throughout all package management
+ programs. This could be done either by changing humanize_size to decimal
+ as well, or changing apt/apt-pkg/strutl.cc to binary, or even by totally
+ eliminating humanize_size and using also the apt subroutines in update-
+ manager.
+
+ As far as I can see there is even another weakness in humanize_size (at
+ least in older versions, I have not checked the most recent ones yet):
+ the localization of the decimal separator is not correct and always
+ displayed as '.' even in 'decimal point is comma' local settings as with
+ German language.
** Changed in: update-manager (Ubuntu)
Status: Confirmed => Triaged
** Changed in: update-manager (Ubuntu)
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to update-manager in Ubuntu.
https://bugs.launchpad.net/bugs/410310
Title:
update-manager inconsistent with download size
Status in Update Manager:
Confirmed
Status in “update-manager” package in Ubuntu:
Triaged
Bug description:
Binary package hint: update-manager
There are three places, where the update-manager states the download size of an update:
-For every package itself
-For all packages together
-During download
The first two and the third one differ. (see attachment - the total and the per-package difference has been fixed in the meantime, the difference between update-manager main window and the progress windows still exists)
When doing an update with update-manager some numbers displayed on screen come from update-manager and some from apt.
And now apt is displaying the numbers with decimal kilos (K=1000), and update-manager is displaying the numbers with binary kilos (K=1024). Even if the float problem is solved, this still gives a difference in display of about 4.8% for Megabyte numbers. (see some more details in my comment #9 above and some of the attached pictures).
Before this bug is set to 'Fix Released' I would like to raise the
question if it would make sense to consistently use one and the same
factor for kilo/mega representation throughout all package management
programs. This could be done either by changing humanize_size to
decimal as well, or changing apt/apt-pkg/strutl.cc to binary, or even
by totally eliminating humanize_size and using also the apt
subroutines in update-manager.
As far as I can see there is even another weakness in humanize_size
(at least in older versions, I have not checked the most recent ones
yet): the localization of the decimal separator is not correct and
always displayed as '.' even in 'decimal point is comma' local
settings as with German language.
To manage notifications about this bug go to:
https://bugs.launchpad.net/update-manager/+bug/410310/+subscriptions
More information about the foundations-bugs
mailing list