You are not logged in.
my longest arch-installation is now about 1,5y old ... and / partition (without /home) is becoming full: 6GB full!!! (only system!) ... i admit, having a lot of things installed, but hey (!) that's really much for only / ...
so i had a look what takes so much space away ...
first i cleaned up the pacman cache:
pacman -Sc
this gave me about 2GB of free space ... :-) ... not bad --- maybe there should be a automatically cronjob in arch that cleans this about once a month ... per default --- that would keep / clean and small, and this would make the hdd r/w faster :-) (small effect but longterm-optimization)
then i cleaned the source-tarball cache for makepkg:
makepkg -c
... this gave me about 1.3GB of free space .. :-) getting better ...
the biggest file on the rest i had on / was:
/var/log/kernel --- 1.7GB big!
-> why is the kernel-log accumulated? don't we have a config where the log is started from new or looped after about 2 or 10MB? why not? how to do this? ... at least on SuSE my kernel log was never that big ... should i post a bug?
The impossible missions are the only ones which succeed.
Offline
A comment about pacman -c
I would prefer to not delete all the package.
In my opinion it is always uselfull have on the disk the last release of the packge or at least of some of them. Just to have an emergency backup just in case.
What I realy do not like is that pacman mantain the files of ALL the version of a package. It would be better to have pacman -c delete all the cache and another option to delete only the old package.
So you have the opportunity to save some space and at the same time keep most recent package backup.
Offline
well ... what i think you think of:
what about additional functionality for arch:
pacman -Sc --notbase --notlibs would let base and libs in the cache but remove the others
The impossible missions are the only ones which succeed.
Offline
I think it is perfect something like this.
If possible it should preserve the package of the current version (the one it download) and the previous one. There is always possible that the current one give problems so I would like to have the possibility to downgrade.
Offline
I think it is perfect something like this.
If possible it should preserve the package of the current version (the one it download) and the previous one. There is always possible that the current one give problems so I would like to have the possibility to downgrade.
Hi,
you really would like to have two OpenOffices or X-servers laying around?
It is a bit messy I think. Actually the cleaning could be done with a shell script
though its nicer to have a pacman option. Someone likes to file feature
request?
bye neri
Offline
you really would like to have two OpenOffices or X-servers laying around?
It is a bit messy I think.
Actually unless you pacman -Sc you have ALL the version around from 0.0.1alpha to 20.10.1
Naturally I am not referring to all the package anyway. I do not mind at all if openoffice does not start or kde crash.
But if exim, Courier or apache are broken I get a bit worried on a production server.
My idea is something like this, during pacman normal upgrade ie of apache:
prev version: apache 2.0.0
inst. version: apache 2.0.1
The two above refer to the file in pacman cache directory
newer version: apache 2.0.2
Pacman download and install 2.0.2, then it delete 2.0.0 and keep 2.0.1.
Something like this already keep under control the size of the dir.
It is a kind of package rotation in the cache, a bit like log rotation.
Offline
Hi Bonobov,
/me was a describing a worst case scenario. I do understand what your
driving at. And your point is good. What could be done? This could be
implemented to pacman directly or we have shellscript which explicitly
handles the cache. Maybe with setting of a "keep-level" concerning the
how many steps you like to keep. Also it should sort out all packages
which aren't installed anymore. Another question, should there be a list
of packages to be kept or not to be kept or should everything be kept
which is currently installed (pacman -Q output). A really tricky task would
be the handling of such pre and b and beta and rc and so on in the version
numbers.
I would like to write it (the shellscript) but I will have examens until the
end of February.
bye neri
Offline