Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 450726

Summary: No way to clean mock cache directory
Product: [Retired] Fedora Hosted Projects Reporter: Paul B Schroeder <paul.schroeder>
Component: mockAssignee: Clark Williams <williams>
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: dcantrell, paulbsch
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-17 21:33:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
A simple, untested patch that removes cachedir on clean
diff of my current git tree which add --scrub option
diff of my current git tree which add --scrub option none

Description Paul B Schroeder 2008-06-10 17:40:00 UTC
Description of problem:
When I use the --clean option, I suppose I expect it to also remove the cache so
that I can truly start clean.  Would be nice if --clean also removed cache.  At
the very least, it would be nice to have a --cleanall option to do this.  And/or
a --cleancache option to just remove the cache.

Version-Release number of selected component (if applicable):
all versions

How reproducible:
mock -r the_chroot --clean
And see that /var/lib/mock/cache/the_chroot_cache is still there..

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Paul B Schroeder 2008-06-10 17:40:00 UTC
Created attachment 308844 [details]
A simple, untested patch that removes cachedir on clean

Comment 2 Clark Williams 2008-09-10 22:29:55 UTC
The --clean option pre-dates the existence of a mock cache, so using it implies that the actual chroot directory will be emptied and repopulated, not that the cache will be affected. 

I'd rather not change the semantics of an existing option, so how about we come up with a new option (or set of them) for root cache manipulation?

How about --clean-cache, or something along those lines? The implication would be that the cache file for the specified configuration would be nuked, which would cause the chroot to be populated via yum (and the cache tarball be regenerated).

   $ mock -r fedora-8-x86_64 --clean-cache my-package-1.0.src.rpm

Comment 3 Paul B Schroeder 2008-09-10 23:07:09 UTC
With your example, I'm not sure if you're saying that the SRPM would be required to "--clean-cache" or not.  I don't see why it would/should be.

I can see keeping "--clean" as is for backward compatibility.  As far as possible additional options I can think of:
--clean-chroot (obvious synonym for --clean)
--clean-cache-all (or simply --clean-cache to clean all of the cache)
--clean-all (does --clean-chroot and --clean-cache-all)

Maybe having all of those options is overkill?, but whatever you see fit.  I'm happy so long as I don't have to become root and use "rm" to clean my root cache.

Comment 4 Clark Williams 2008-09-11 20:08:40 UTC
We can make sure that you don't need an SRPM just to manipulate the caches. And we definitely don't want you to have to go mucking around with the cache's by hand :)

What if we made --clean take an optional argument?

--clean={chroot, root-cache, yum-cache, all} - default == chroot

that way --clean keeps its current semantics, while if you want to manipulate the root cache, you could specify --clean=root-cache. It's possible we could handle something like --clean=root-cache,yum-cache  as well. Or you could just add multiple --cleans, e.g. --clean=root-cache --clean=yum-cache.

Since all these guys are handled by plugins, if I figure out how to do it cleanly with one I should be good for all of them (he said confidently...).

Comment 5 Paul B Schroeder 2008-09-11 20:24:53 UTC
Sounds great!  And that's definitely "clean"er that having all the separate cmdline options.  ;)

Comment 6 Clark Williams 2008-11-07 03:32:20 UTC
Ugh. The optparse package doesn't allow optional arguments. 

Since I'm not really up for rewriting the mock option processing code, I think we're back to one of these scenarios:

1. Change the --clean switch to take a required argument (not preferred)
2. Add a new option that takes the specified arguments 
3. Add individual options (like in comment #3)

I think my preference would be for option 2, where we come up with some option name that takes one of {chroot, root-cache, yum-cache, all} as an argument. 


Comment 7 Paul B Schroeder 2009-02-03 22:45:02 UTC
Don't think you're waiting on a reply from me..  But just in case. . . .
--scrub sounds fine to me..

Comment 8 Paul B Schroeder 2010-06-29 23:26:49 UTC
Created attachment 427822 [details]
diff of my current git tree which add --scrub option

This finally bugged me enough that I went ahead and put this together.

This patch is a diff of my current git tree which adds a --scrub option.  I'm not 100% familiar with the mock internals (so it may need some modification), but it seems to work just fine.  Multiple scrubs can be specified.
mock -r fedora-13-x86_64 --scrub=c-cache --scrub=root-cache
mock -r fedora-13-x86_64 --scrub=chroot --scrub=root-cache

Please let me know if it needs any modifications in order to be applied.

As an aside, it also has a fix for custom dev mounting ( ) at the end of it which can easily be separated out.

Comment 9 Paul B Schroeder 2010-06-30 21:00:43 UTC
Created attachment 428099 [details]
diff of my current git tree which add --scrub option

Same as the previous diff of my git tree..  But has _umountall update for ( )

Comment 10 Clark Williams 2010-07-16 14:56:18 UTC
patch merged for release with mock-1.1.2

Comment 11 Fedora Update System 2010-08-07 23:23:28 UTC
mock-1.1.3-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.