Hi! I like this patch. Sometimes (-Sp, for example) it is needless to compute this info, so this little speed-up is one more minor argument for on-demand download-size computing.
> Here is a patch to resolve FS#18769. I created a new INFRQ/infolevel to > describe package download size, so that it could be lazily calculated > like most of the other package info. This differs slightly from most of > the other infolevels, which correspond to information actually read by > _alpm_db_read and alpm_pkg_load. However, I felt it better to do it this > way than setting the download size to -1 for invalid, as this would make > it the only field in pmpkg_t that needs to be initialized to something > other than 0. I also came up with these two possible solutions earlier, see 5. here: http://mailman.archlinux.org/pipermail/pacman-dev/2008-August/007512.html Now I also think that infolevel is better. > It is also possible that the download size will be reported incorrectly > if a package download size is read, and then that same package is > downloaded with alpm_fetch_pkgurl. However, this is better than the > present situation where download sizes aren't reported at all, and > furthermore this is unlikely since alpm_fetch_pkgurl would probably not > be used to download a package that is in the repositories. I agree, alpm_fetch_pkgurl is not used by alpm. Moreover, in my opinion (see also the thread above), our download code is quite messy. That's why this is needed: + for(j = trans->add; j; j = j->next) { + j->infolevel &= ~INFRQ_DSIZE; + j->download_size = 0; + } Clearly we should somehow restructure our download code to handle pmpkg_t's. Bye
