> 2.9 > - Added compressed package size to sync DBs -- shows the total size of > packages before downloading > > > Now it should indeed be a small effort to add the size of the individual > packages.
The *compressed* size, that is. Unfortunately, what most people ask for is the amount of hard disk space that is going to be required for installation of the package, ie. the *uncompressed* size of a package. Thinking about it, though, it seems at a first glance relatively simple to 'du' the size of the fakeroot during makepkg packaging, right before the package tarball is created, and save this info in the package meta data. This won't work for packages that generate/modify any files with install scripts, but might be a "close enough" approximation, codable with little effort into makepkg. Size of packages with generated files may be taken care of with an explicitly set "uncompressed size" directive in the PKGBUILD, for example, which is chosen by the packager appropriately. Instead of rebuilding all packages currently in existance to include the "uncompressed size" in the metadata (don't even THINK about it), it would suffice to uncompress a package once into a fake root, record the uncompressed size, and add this information as the missing "uncompressed size" field to the metadata. Repeat for all packages => transition done. In case "uncompressed size" field does not exist, use "1.5*compressed size" as a default guess to have *some* value to work with until all packages use the new metadata field. Is this feasible? I'm not at all into the makepkg/pacman code, so this is all insane rambling. In case this *is* feasible, though, and eventually to be implemented, I explicitly offer to write up the necessary script(s) to convert the database of current and extra. Unless someone else with more spare time at hand would like to take care of this. *cough* Having a good approximation of needed HDD space for package installation would actually prevent some considerably dumb problems from happening. (insert reference to ugly pacman behavior on filled up partitions here) Regards, Dennis _______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
