Bug 450726 - No way to clean mock cache directory
No way to clean mock cache directory
Product: Fedora Hosted Projects
Classification: Retired
Component: mock (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Clark Williams
Depends On:
  Show dependency treegraph
Reported: 2008-06-10 13:40 EDT by Paul B Schroeder
Modified: 2013-01-09 23:43 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-08-17 17:33:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A simple, untested patch that removes cachedir on clean (383 bytes, patch)
2008-06-10 13:40 EDT, Paul B Schroeder
no flags Details | Diff
diff of my current git tree which add --scrub option (4.67 KB, patch)
2010-06-29 19:26 EDT, Paul B Schroeder
no flags Details | Diff
diff of my current git tree which add --scrub option (5.11 KB, patch)
2010-06-30 17:00 EDT, Paul B Schroeder
no flags Details | Diff

  None (edit)
Description Paul B Schroeder 2008-06-10 13:40:00 EDT
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 13:40:00 EDT
Created attachment 308844 [details]
A simple, untested patch that removes cachedir on clean
Comment 2 Clark Williams 2008-09-10 18:29:55 EDT
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 19:07:09 EDT
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 16:08:40 EDT
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 16:24:53 EDT
Sounds great!  And that's definitely "clean"er that having all the separate cmdline options.  ;)
Comment 6 Clark Williams 2008-11-06 22:32:20 EST
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 17:45:02 EST
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 19:26:49 EDT
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 ( https://fedorahosted.org/mock/ticket/8 ) at the end of it which can easily be separated out.
Comment 9 Paul B Schroeder 2010-06-30 17:00:43 EDT
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 ( https://fedorahosted.org/mock/ticket/8 )
Comment 10 Clark Williams 2010-07-16 10:56:18 EDT
patch merged for release with mock-1.1.2
Comment 11 Fedora Update System 2010-08-07 19:23:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.