[pacman-dev] [PATCH] cachemoney: add new contrib script

[Dave Reisner]

On Sun, Jul 31, 2011 at 01:47:03PM +1000, Allan McRae wrote:
> On 29/07/11 00:36, Dave Reisner wrote:
> >On Wed, Jul 27, 2011 at 05:39:46PM -0400, Eric Bélanger wrote:
> >>On Wed, Jul 27, 2011 at 3:13 PM, Dave Reisner<d at falconindy.com>  wrote:
> >>>cachemoney is a robust and flexible package cache cleaner with a variety
> >>>of options. Much credit goes to DJ Mills and Pat Brisbin for the ideas
> >>>behind this script.
> >>>
> >>>Signed-off-by: Dave Reisner<dreisner at archlinux.org>
> >>>---
> >>>This sort of functionality has been in a few feature requests, and there exist
> >>>a number of tools that already provide this, but none flexible enough (or
> >>>portable enough) to be to my liking. This is all bash3 compat with awk, tested
> >>>on gawk 3.1.8, gawk 4.0.0, bwk (the one true), mawk, and busybox awk (which
> >>>fscking _sucks_) to do the heavy lifting (rather than bash4). It ends up being
> >>>insanely fast, with the drawback being that its dependent on the format of the
> >>>filename to find and consider packages for deletion. In other words, a valid
> >>>package tarball that isn't compliant with the extglob *.pkg.tar?(.+([^.]))
> >>>isn't going to be considered.
> >>>
> >>>I'm a fan of the name, but I'm also happy to hear alternatives.
> >>>
> >>
> >>Without having tested it, that script might be something I will use
> >>but I don't like the current name. I just don't understand the 'money'
> >>part in it. A name like cachecleaner would be more intuitive.
> >>
> >
> >It's mostly just a bad joke[1]. I'll throw out the following
> >alternatives:
> 
> I'll add a -1 for the current name too...   Bad jokes are usually a
> bit funny! :P
> 

Nothin' but a bunch of haters!

> >* slimcache
> >* paccache-clean (more "standard", but too long imo)
> >* cachetrim
> >* pacuum
> 
> How about just paccache?  A description line about the usage output
> would be helpful in figuring out what this does too...
> 

paccache actually sits well with me... adding a bit to the usage should
do nicely to sell it.

> 
> Do this script cover all or most of the features of these scripts?
> I'm sure the maintainers would be "happy" if there is a name
> conflict if the script we supply covers their functionality.
> 

Time to re-review!

> >* cacheclean

Python. Supports N number of copies to keep from hardcoded cache
location with a preview function. Requires that it be run as root. I get
a backtrace running it with python2 or python3.

> >* pacleaner

Python. Supports deletion of uninstalled packages, cached packages, or
both. Hardcodes the cache location. So really, this seems to just
emulate -Sc,-Scc. I get a backtrace running it with python2 or python3.

> >* pkgcacheclean

C, linked against alpm. Supports N number of copies to keep with a
compile time hardcoded cache location. Allows for dry runs. Inflexible
output. Offers diskspace saved in bytes. Compiles, but not against git.

> >* clearcache

bash4. Its nearly at feature parity with mine. Doesn't offer the same
level of output control or the ability to move packages. It's written by
DJ Mills, so this one actually works. It has the interesting approach of
extracting and parsing the .PKGINFO file from each .pkg.tar?(.*) so its
possibly more accurate, but very slow. This is the only one worth
talking about in comparison with mine.

> >* pacprune

Late entry. Pat Brisbin's bash script which is meant to be mostly
utilitarian, but scores extremely high in that category. Doesn't,
however, offer the ability to do things like prune uninstalled packages
easily. Size calculations is possible for the crafty, but not inline
with another operation.

> >Any feedback on functionality? Anyone manage to break it?
> 
> I can not really test well as I have a somewhat unique cache set-up
> and my own cache cleaning script  (which has the additional feature
> of always keeping packages that have versions newer than what is in
> the repos).
> 
> Allan
> 

Now _that_ is an interesting feature. Sadly, the code path I've gone
down probably isn't flexible enough to handle this as eloquently as I'd
like.

d