2007/1/10, Dennis Herbrich <[EMAIL PROTECTED]>: > > 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)
This is already implemented in pacman3. But you will not see this when using pacman-rc-3.0.0 yet, because dbs should be regenerated to contain this info. However you can test this with gensync from pacman3. -- Roman Kyrylych (Роман Кирилич) _______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
