You are not logged in.
Hi, I did not find any info about this on the forums, so I though let's just post it.
The issue is that after I upgraded to gcc 4.2.1-3, glibc 2.6.1-1 and kernel26 2.6.22.3-1 it seems I lost a good 100mb of HD space in the process. I have made sure my pacman cache and /tmp was clear of any leftovers. Since I am on an old computer with a small HD, this is a rather big problem for me, as I now have just (eek!) 16mb of HD space left on my Arch partition.
Anyone have any idea what might be causing this, and if possible, how to 'fix' it?
Thank you in advance.
Last edited by Lava Croft (2007-08-26 07:47:25)
Like any dealer I am looking for the car that is so high and wild, I'll never have to deal another.
Offline
I indeed see a huge increase of size with last gcc and glibc packages (not kernel26 though) :
-rw-r--r-- 1 root root 13M jui 5 08:09 gcc-4.2.1-1.pkg.tar.gz
-rw-r--r-- 1 root root 36M aoû 8 09:07 gcc-4.2.1-3.pkg.tar.gz
-rw-r--r-- 1 root root 11M jun 5 12:33 glibc-2.6-2.pkg.tar.gz
-rw-r--r-- 1 root root 21M aoû 8 09:06 glibc-2.6.1-1.pkg.tar.gz
And that's compressed size. uncompressed, that's apparently a 84 MB difference .
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
Well, I wasn't sure exactly what package caused the 'problem', but yeah, the difference in size is quite big. I wonder if there is any justification for this.
Like any dealer I am looking for the car that is so high and wild, I'll never have to deal another.
Offline
It seems these packages were compiled with debug symbols enabled. Don't know how they get there, but it should be gone by the weekend.
Offline
Oh, didn't even think about checking that
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
It seems these packages were compiled with debug symbols enabled. Don't know how they get there, but it should be gone by the weekend.
Heh, thanks for pointing it out. Looking forward to updating it. Is it safe to force pacman to remove the packages, ignoring the depencies, and then install the updated package?
Like any dealer I am looking for the car that is so high and wild, I'll never have to deal another.
Offline
Heh, thanks for pointing it out. Looking forward to updating it. Is it safe to force pacman to remove the packages, ignoring the depencies, and then install the updated package?
Hmmmm.... probably not. gcc and glibc provide libraries that loooooots of apps need to run. If you don't have space for the DL, you might consider temporarily removing some non-essential packages to do the upgrade.
Offline
But inbetween the removal of the packages and installing them again I do not require to run any application besides pacman...
Like any dealer I am looking for the car that is so high and wild, I'll never have to deal another.
Offline
Yeah, and pacman is built in C and so requires (at least) glibc. pacman.static may not have that dependency; I'm not sure if you can statically compile in the c library.
Offline
But inbetween the removal of the packages and installing them again I do not require to run any application besides pacman...
pacman won't run either though though pacman.static apparently does, I just tried it.
I'm not guarantying anything though, so if it breaks your box beyond repair, don't complain
What about getting a new hd for avoiding all these unneeded troubles ? Space is cheap these days.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
You can strip these libraries by hand to get some space back.
The /usr/lib/gconv directory contains a lot of libraries, on my amd64 system with stripped symbols they take up 7.3MB, on i686 this should be double size with debug symbols.
strip --strip-unneeded /usr/lib/gconv/*.so
You could do this for all .so files in gcc and glibc if you want to save space before updating.
Offline
Thank you for the helpful replies.
@shining: You convinced me, I'll just take the safe route.
@JGC: I understand strip --strip-unneeded /usr/lib/gconv/*.so, but I do not get what you mean with You could do this for all .so files in gcc and glibc.
Could you please explain a bit more?
Again, thanks in advance.
Like any dealer I am looking for the car that is so high and wild, I'll never have to deal another.
Offline
Thank you for the helpful replies.
@shining: You convinced me, I'll just take the safe route.
@JGC: I understand strip --strip-unneeded /usr/lib/gconv/*.so, but I do not get what you mean with You could do this for all .so files in gcc and glibc.
Could you please explain a bit more?Again, thanks in advance.
Well, glibc and gcc have other .so files that you can strip.
See : pacman -Ql glibc gcc | grep "so$"
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
I stripped the files and updated the packages, case solved.
Thanks for your help!
Like any dealer I am looking for the car that is so high and wild, I'll never have to deal another.
Offline