pkg upgrade requires 1 GiB more space, why?

F

fwyKKCkQze2z

I am running a pkg upgrade on my FreeBSD 11.0 system and get the following output:

Code: 
-----
Number of packages to be removed: 1
Number of packages to be installed: 3
Number of packages to be upgraded: 56
Number of packages to be reinstalled: 42

The process will require 1 GiB more space.
3 MiB to be downloaded.
-----

That particular machine does not have a lot of memory, so I am concerned about the +1 GiB used. If the software I have installed really requires this, I will have to "invest" that diskspace, but I wonder why new versions of already installed packages will require so much more space?

Is there a way to identify the package(s) which require more space? After all, only 3 MiB will be downloaded?

BTW: the "installed" ones (the ones that are "new" in pkg lingo, I assume) are
  • llvm39: 3.9.1_4
  • py27-setuptools: 32.1.0_1
  • lua52: 5.2.4
They are dependencies of other, installed, packages I guess (py27-setuptools27 is being removed, so I assume adding py27-setuptools is more or less a "no-op" diskspace wise).
 
fwyKKCkQze2z said:
3 MiB to be downloaded.
Click to expand...
This is probably not right. I am using FreeBSD 11 Release and pkg upgrade is pushing llvm40 now and it is a large download.
This is using the 'latest' setting for repository.

Fetching llvm39-3.9.1_5.txz: 100% 244 MiB 5.7MB/s 00:45
 
I think pkg is just misreporting what will actually be done.

I have no data on this, but I occasionally get similar messages. What I think this means is that the new versions/updates will take up 1GB, but it doesn't tell you that the old versions will be uninstalled, and therefore reduce the space taken.

In effect, you may only "lose" the space required by the new packages, more or less.
 
Phishfry said:
This is probably not right. I am using FreeBSD 11 Release and pkg upgrade is pushing llvm40 now and it is a large download.
This is using the 'latest' setting for repository.

Fetching llvm39-3.9.1_5.txz: 100% 244 MiB 5.7MB/s 00:45
Click to expand...
Maybe OP downloaded some of them already.
 
Maxnix said:
Maybe OP downloaded some of them already.
Click to expand...

This seems to be correct (i.e. explains why a "3 MiB" download can use 1 GiB of space).

Turned out that it was llvm using all that space (it really used +1 GiB when I decided to allow pkg to upgrade). By using pkg -d and pkg -r I figured out that the reason for installing llvm was rrdtools. I am not willing to spend so much disk for rrdtools, so I removed it and reclaimed my precious 1 GiB.

But part of the original question still stands: (how) can I generically identify why/what will be using up more space when running a pkg upgrade?
 
If you allow the upgrade to complete, then run # pkg autoremove, most of that space will be freed. I am guessing that a new version of llvm is being installed and you will no longer need the older version.
 
I'm not sure how pkg(8) calculates the space requirements. But it's possible it simply adds up everything that needs to be installed (or reinstalled) and doesn't subtract anything that's going to be uninstalled (or is already installed).
 
I had same issue than OP, any idea why LLVM package went from 168Mb in llvm37 to 1.17Gb in llvm39?

Code: 
root@server1:/usr/local/llvm37 # du -d 1 -h
 13M    ./include
228K    ./share
4.2M    ./bin
 18K    ./libexec
 60M    ./lib
 78M    .

----

Code: 
root@server2:/usr/local/llvm39 # du -d 1 -h
 27M    ./include
659M    ./bin
129K    ./share
 23K    ./libexec
518M    ./lib
1.2G    .
 
amontalban said:
I had same issue than OP, any idea why LLVM package went from 168Mb in llvm37 to 1.17Gb in llvm39?
Click to expand...

I think what amontalban means is this (bringing the newly learned command into action):

Code: 
$ sudo pkg rquery %sh llvm37
166MiB
$ sudo pkg rquery %sh llvm38
975MiB
$ sudo pkg rquery %sh llvm39
1.11GiB
 
Here is the next version. My machine:
Code: 
# pkg rquery %sh llvm36
111MiB
# pkg rquery %sh llvm37
# pkg rquery %sh llvm38
975MiB
# pkg rquery %sh llvm39
1.11GiB
# pkg rquery %sh llvm40
1.32GiB
 
You must log in or register to reply here.
Back
Top