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)



Subject: non-interactive CPAN ignores build_cache size
Download (untitled) / with headers
text/plain 765b
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
Download (untitled) / with headers
text/plain 609b
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.
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. > >
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>
Download (untitled) / with headers
text/plain 995b
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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.