On 10/16/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 10/16/07, Nathan Jones <nathanj@insightbb.com> wrote:
On Mon, Oct 15, 2007 at 09:59:07PM -0500, Dan McGee wrote:
+unsigned long SYMEXPORT alpm_pkg_download_size(pmpkg_t *newpkg, pmdb_t *db_local) +{ + char *fpath = _alpm_filecache_find(alpm_pkg_get_filename(newpkg)); + unsigned long size = 0; + + if(fpath) { + size = 0; + } else if(handle->usedelta) { + alpm_list_t *deltas = pkg_upgrade_delta_path(newpkg, db_local); + + if(deltas) { + size = _alpm_delta_path_size_uncached(deltas);
Does this account for the delta is greater than 0.7 of the size case?
When finding the shortest delta path, the code does not look to the cache to see if the file already exists. This function takes whatever delta files will actually be used and calculates the remaining downloaded size for the client to display, using 0 if a delta exists in the cache.
- /* round up if size is really small */ - if(mbrsize < 0.1) { - mbrsize = 0.1; - }
Any reason for removing this?
I removed it because it doesn't make as much sense with the download size. For example, downloading a 30K package would display 100K for the total package size but 30K for the download size.
The download size could be rounded as well, but it is possible for it to be 0K if the file already exists in the cache, so displaying 100K would not be correct.
I was thinking the installed size/package size always displayed as MB. I know that when downloading we use K until we reach a certain point, but I thought the initial display of sizes is done all in MB.
-Dan
Some example output: $ pacS 855resolution resolving dependencies... done. looking for inter-conflicts... done. Targets: 855resolution-0.4-5 Total Package Size: 0.10 MB Proceed with installation? [Y/n] Since we print the values to 2 decimal places, we should probably round to 0.01 instead of 0.1. Or like you said, we could just get rid of the rounding. I'll do this on my local branch, I like your original thinking. :) -Dan