Skip Menu |

This queue is for tickets about the CPAN CPAN distribution.

Report information
The Basics
Id: 33685
Status: open
Priority: 0/
Queue: CPAN
People
Owner: Nobody in particular
Requestors: pause [...] tlinx.org
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: 1.9205
Fixed in: (no value)

History Show all quoted text
  Thu Feb 28 21:49:50 2008 pause [...] tlinx.org - Ticket created
Subject: non-interactive CPAN ignores build_cache size
I was running a bunch of installs of modules that needed updating and I noticed my "/var/cache/cpan" dir was getting a bit large... Show quoted text
> du -sk /var/cache/CPAN
2036762 /var/cache/cpan # 2Gig? but my "Config" says: Show quoted text
> grep build_cache .cpan/cpan/MyConfig.pm
'build_cache' => q[64], ---- I was running the "installs" via the command line: Show quoted text
> perl -MCPAN -e "install(\"$modname\");"
--- As soon as I ran it interactively, it began deleting the "excess"...: Scanning cache /var/cache/CPAN/build for sizes: .........------------------------------------------------------------ -------DONE DEL(1/318): /var/cache/CPAN/build/Tk-804.028-TjcdEP.yml DEL(2/318): /var/cache/CPAN/build/Bundle-CPAN-1.857-BKO3X9 DEL(3/318): /var/cache/CPAN/build/Test-Harness-3.09-X_Mg47
  Thu Feb 28 22:17:34 2008 ANDK [...] cpan.org - Correspondence added
What a coincidence. Yesterday I added this to the CPAN.pm documentation: | Speaking of the build directory. Do I have to clean it up myself? | You have the choice to set the config variable C<scan_cache> to | C<never>. Then you must clean it up yourself. The other possible | value, C<atstart> only cleans up the build directory when you start | the CPAN shell. If you never start up the CPAN shell, you probably | also have to clean up the build directory yourself. At the moment I have no plans to change this, mostly because I have no ideas how it could be improved without getting overly complicated.
  Thu Feb 28 22:17:44 2008 The RT System itself - Status changed from 'new' to 'open'
  Thu Feb 28 23:40:53 2008 dagolden [...] cpan.org - Correspondence added
Subject: Re: [rt.cpan.org #33685] non-interactive CPAN ignores build_cache size
Date: Thu, 28 Feb 2008 23:40:35 -0500
To: bug-CPAN [...] rt.cpan.org
From: "David Golden" <dagolden [...] cpan.org>
Funny you should mention this indeed. I just hacked support for it into CPAN::Mini::Devel. (I.e., setup locking, create new cache manager object, remove locking at the end.) There's probably a way to be smart about that even without the shell if "atstart" is the option. David On Thu, Feb 28, 2008 at 10:17 PM, Andreas Koenig via RT <bug-CPAN@rt.cpan.org> wrote: Show quoted text
> > Queue: CPAN > > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=33685 > > > What a coincidence. Yesterday I added this to the CPAN.pm documentation: > > | Speaking of the build directory. Do I have to clean it up myself? > > | You have the choice to set the config variable C<scan_cache> to > | C<never>. Then you must clean it up yourself. The other possible > | value, C<atstart> only cleans up the build directory when you start > | the CPAN shell. If you never start up the CPAN shell, you probably > | also have to clean up the build directory yourself. > > > At the moment I have no plans to change this, mostly because I have no > ideas how it could be improved without getting overly complicated. > >
  Thu Feb 28 23:58:12 2008 pause [...] tlinx.org - Correspondence added
Subject: Re: [rt.cpan.org #33685] non-interactive CPAN ignores build_cache size
Date: Thu, 28 Feb 2008 20:57:55 -0800
To: bug-CPAN [...] rt.cpan.org
From: "L. A. Walsh" <pause [...] tlinx.org>
Hmmm....I agree it's not a pretty situation -- the disk check and delete take up a fair amount of time on even a "primitive", RAID-0 15K-SAS drives...(*cough*).... Unfortuantely, I'm somewhat serious about the check taking a bit of time -- at least under cygwin. OTOH...yuck...too bad "atstart" already means "at_shell_start", a different "atstart" value doesn't seem overly complicated as an option. As far as 'speeding up' the check...I might also have the build_cache have a "number of items" (like I could limit it to < 60 packages, in addition to < 64Meg) limit...but that's off the top of my head and it does seem a bit imprecise if not outright kludgey... As far as "locking" the cache, FWIW, I was trying to build multiple packages in parallel (which was why I was invoking CPAN outside of the cpan->shell). While locking can be (and often is) a good thing, I hope it wouldn't abort in-parallel module building considering that's the only way to start tapping multiple CPU's.