Guillem Jover <guil...@debian.org> writes: > On Wed, 2015-01-07 at 12:22:47 +0100, Johannes Schauer wrote:
>> It is also worth asking what functionality the Installed-Size field is >> supposed to have when looking for a solution. It's primary purpose is >> probably to give apt a clue of whether or not there is enough free >> space to install a certain package. > Personally I've always taken it as a small hint of the approx. size of > the package, but the most interesting case which is always accurate is > to spot size differences between the previous and next package version, > for example from aptitude TUI. I consider the primary purpose to be to give a *human* a hint as to how large the package is. At least, that's how I've always used it. For that purpose, it really only needs to be accurate within a few hundred KB, and overstating the package size is probably better than understating it for packages with, say, large sparse files. It helps avoid problems like "oh, this game looks interesting -- ack, where did all of my disk space go?" If it can also provide information to apt about whether a package will fit on the disk, that's great, but I don't think we should put too much weight on that. Operating package managers very close to a full disk is a problematic action anyway, since there are a bunch of intermediate steps involved in installing a package, other files that get created dynamically, and so forth, and it's very hard to predict how much space will be required to successfully complete the installation. Certainly, Installed-Size doesn't do that. So, from a Policy perspective, I'd be happy with language that says this is an approximation of the size of the package on disk and leave it at that. It's tempting to generate it by just summing the sizes of the files in the Debian package after rounding them up to some common file system block size and not try to get too fancy. Of course, if people want to work on making the number more accurate, I won't stand in their way, but I don't think the reasonable uses for the field require that. > Take into account that usually other disk usage is not accounted, like > files generated at run-time, caches, logs and similar. There's the > Extra-Size substvar just for that but I don't think any package is > actually making use of it (at least according to codesearch.d.o), so… Yeah. Because knowing that to put in that field is a rather hard problem. > Also apt (and cupt) only use that information to print the size deltas, > apt only actually checks for available disk size for downloaded data, > which is the only thing that actually makes sense doing. Yup. > Given that (at least apt and cupt) are not actually comparing the > available disk space with the accumulated packages Installed-Size, there > will be no warning anyway, and to me just making dpkg fail gracefully on > ENOSPC is the best option, anything else will just be wrong > somewhere. +1. > I think preventing package installation through Installed-Size would be > a bad idea and quite annoying because it could disallow possible > installations which would be even more confusing. +1. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
