The latest version of portage, 2.0.47-r8 has a bug for people that use cvs ebuilds. Regardless of what the permissions are on /usr/portage/distfiles/cvs-src, everytime portage tries to do anything it unnessicarily tries to change the permissions and ownership recursively on that directory. This leads to severe slowdowns right before portage downloads a file, before it compiles everything, and before it generates the ld.so.cache...not to mention before it calculates what needs to be clean, and before every package that it cleans. This gets to be insanely long taking even 30 minutes to build a package of size 37k...so, for people using live cvs ebuilds, r8 is a deathtrap, as in the slowdown process, portage consumes and does not release lots of memory, and after a few ebuilds, it's not uncommon to be hitting swap. Reproducible: Always Steps to Reproduce: 1. Emerge a CVS Ebuild (gaim-cvs,galeon-cvs, etc...) 2. Update to portage-2.0.47-r8 3. Resist the urge to curse! Actual Results: Portage became slow as hell and almost unusable. I would rather use LFS than wait 30 minutes for something that should take 2. Expected Results: It should have not changed in speed at all. What took two minutes before should still take two minutes. I was running fluxbox, gnump3d, gaim-cvs, epiphany-cvs, and evolution.
alright, i guess this is becuase cvs-src can be huge in terms of number of files... i guess we could simply not do this chown every emerge.... or we need to rework the way the cvs eclass does things.... possible ideas? does the cvs co, then tarbz2's that directory... then that is unpacked in the unpack phase... to update it checks for the live cvs tarbz2, unpacks its...cvs updates, repacks it? let me know what you think nick
*** This bug has been marked as a duplicate of 16768 ***
