| Summary: | eclean enhancment portage logs and /var/tmp/portage | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | David J Cozatt <djcozatt> |
| Component: | Current packages | Assignee: | Portage Tools Team <tools-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | esigra, serkan |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 346443 | ||
|
Description
David J Cozatt
2011-01-18 00:27:46 UTC
If we decide to do this, let's target for 0.3.1 Great idea. I just checked and was duly horrified to find that /var/log/portage is 2.4G, and has logs going back into the mists of time, so possibly this might be included too. You can also use FEATURES=clean-logs to have emerge automatically remove old logs. See `man make.conf` if you're interested. I have also added a new emaint module by moving the log cleaning code from emerge to an emaint module. Emerge will still do automatic log cleaning for you by running the code in the emaint module. I also added options to do a pretend check and option to override the default time with a new value. It can also be set to 0 (zero) to remove all the pkg logs. This way log cleaning can be done automatically, and/or manually by running emaint. It is currently in the emaint branch in my github portage repo waiting for review and integration into portage. https://github.com/dol-sen/portage Please test it and report your success, not just any problems you encounter. As there was a lot of change to the code, it would help Zac to know it has been tested quite extensively. The code does not need to be installed to run, it can run from the git checkout as long as you add the correct path to PATH & PYTHONPATH so it can find the bin and python modules there. Adding log cleaning to eclean should be quite easy. One method would use the new emaint module, but would not include the file size info. Another would be to create an eclean style module which would include the file size info. As for the PORTAGE_TMPDIR a module could be created for the emaint rewrite mentioned above. Which it too could be imported and used in eclean as part of it's operation. (In reply to comment #4) > I have also added a new emaint module by moving the log cleaning code from > emerge to an emaint module. That's release in portage-2.1.11.10 and 2.2.0_alpha121: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9e19ac0a16a57f3dded8124e650fb6bf6f3d00be Thank you very much for your work on this...I have done some testing ... a few comments. It seems that the timestamp is the driving decision maker in the case of cleaning the logs (from reading the make.conf entry and what little usage testing I have done); while this is far better than nothing it is not what I would consider ideal. In the best case scenario (and I realize that it would be much more difficult to implement)the latest build log would be retained and anything removed by say a --depclean or a previous version would be removed. So the best case would weem to be to have only the latest build log of any installed application/etc on the machine and that would be retained by default until removed by an updated log. Nevertheless...I see no reason why this cannot be in stable. I found no issues. And thanks again. #emerge -ep world -->Total: 1159 packages (2 upgrades, 1 downgrade, 1156 reinstalls), Size of downloads: 4,308 kB penguin4 david # ls /var/log/portage/ | wc 4186 4186 198879 Several 'emerge -e' done recently contributed to the number of logs above done since gcc and a few other things were done ...including removing gnome and moving on to kde. That said if the latest build log were the criteria and not timestamps I should have 1159 logs and not 4186 I realize that would mean a lot of work though and likely a database to consult though eix is installed and might provide the needed info. Closing this as done since the cleaning is done now. Still would like to see portage remove previous logs for each pkg as it installs the new build log. Should be easier I would think to just remove old ones when the new one is installed since portage at that moment has the $PATH and $name on installing the log(s). As well it would seem to be proper to remove old build logs when uninstalling a package. Of course feel free to disagree and if you feel the need to reopen |
