Bug 164078 – [patch] CLEAN_DELAY only on explicit unmerge

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Dan 2007-01-27 17:46:11 UTC]

Currently, portage gives a CLEAN_DELAY during implicit unmerges (cleaning oldversions of packages after merging new one).  This can add a lot of time.  With it assumed that the user is not watching the merges, it seems like it should not give the clean delay during implicit unmerges.  This patch changes it so that there is no CLEAN_DELAY when unmerge is called from merge.  The CLEAN_DELAY is still used for prune, depclean, and clean.  As an idea of numbers, on a -e world with 400 packages it takes an extra 33 minutes of just waiting to clean.  On an 800 package -e world, its over an hour.  I have just been setting CLEAN_DELAY to be 0 in make.conf, but that is less than desirable because it does not allow to check the output on --unmerge.

Patch follows, I'm no python guru so it may need small modifications (or large ones!)

[Comment 1 Dan 2007-01-27 17:46:47 UTC]

Created attachment 108297 [details, diff]
only delay on manual emerge

Heres the patch

[Comment 2 Zac Medico 2007-01-28 23:37:07 UTC]

I'm not even sure why CLEAN_DELAY exists in the first place.  I have it set to 0  because I've always thought it was stupid.  If you want to be careful about what's unmerged, you should be using --pretend or --ask anyway.  So, I don't see a point in differentiating between manual and automatic unmerges.

[Comment 3 Zac Medico 2007-01-29 01:17:09 UTC]

Thanks.  I've applied a slightly modified version of your patch in svn r5827.

[Comment 4 Zac Medico 2007-01-29 03:23:52 UTC]

This has been released in 2.1.2-r5.