Skip Menu |
 

This queue is for tickets about the CPAN CPAN distribution.

Report information
The Basics
Id: 91646
Status: open
Priority: 0/
Queue: CPAN

People
Owner: Nobody in particular
Requestors: pause [...] tlinx.org
Cc: CHORNY [...] cpan.org
AdminCc:

Bug Information
Severity: (no value)
Broken in: 2.00
Fixed in: (no value)



Subject: install of SQlite prevents parallel cpan builds due to locking
Download (untitled) / with headers
text/plain 1.1k
I had a cpan build running in one window with cpan -i xxxx. In another windows tried to install something else w/cpan -i... but it got locked out due to SQlite installation: Show quoted text
w> cpan -i Inline
CPAN: CPAN::SQLite loaded ok (v0.203) Database was generated on Tue, 24 Dec 2013 22:01:05 GMT DBD::SQLite::st execute failed: database is locked at /usr/lib/perl5/site_perl/5.16.2/CPAN/SQLite/DBI/Search.pm line 99. DBD::SQLite::st execute failed: database is locked at /usr/lib/perl5/site_perl/5.16.2/CPAN/SQLite/DBI/Search.pm line 99. ----------------------- Also tried cpan -F: but that is also broken: from the pod: -F Turn off CPAN.pm's attempts to lock anything. You should be careful with this since you might end up with multiple scripts trying to muck in the same directory. This isn't so much of a concern if you're loading a special config with "-j", and that config sets up its own work directories. ---- Error is: cpan -F -i Inline Unknown option: F /usr/bin/cpan script version 1.61, CPAN.pm version 2.00 perl 5.16.2
Subject: Re: [rt.cpan.org #91646] install of SQlite prevents parallel cpan builds due to locking
Date: Fri, 27 Dec 2013 00:36:43 +0400
To: bug-CPAN [...] rt.cpan.org
From: brian d foy <bdfoy [...] cpan.org>
Download (untitled) / with headers
text/plain 278b
I'll look at the -F option, but it wouldn't fix any issues with SQLite since that's a database locking issue and not something CPAN.pm can control separately. And remember, you don't need the -i option for cpan(1) if it's the only option. You can just say `cpan Some::Module`.
On Thu Dec 26 15:37:32 2013, BDFOY wrote: Show quoted text
> I'll look at the -F option, but it wouldn't fix any issues with SQLite > since that's a database locking issue and not something CPAN.pm can > control separately. > > And remember, you don't need the -i option for cpan(1) if it's the > only option. You can just say `cpan Some::Module`.
---- Well, if "-F" doesn't come up as illegal, that might help, but if it needs SQLite to function at all, that might be an issue. I.e. "cpan" (even interactively), would need only acquire R/W access to cpan from a stat of holding *no access* (not from read or read-only or that could introduce deadlock problems) and then release any full R/W locks when not needed or it might block other cpan instances that have asked for no-locking but still want to be able to read the DB. (the above based on general locking knowledge and no specific knowledge of SQLite)... I.e. if SQLite is going to be the desire DB, and if it won't allow a reader access while someone else holds a R/W lock, then other CPAN instances need to only hold such locks for a minimal period... Is that doable?
Download (untitled) / with headers
text/plain 142b
This is due to change in DBD::SQLite. Patch is here https://rt.cpan.org/Ticket/Display.html?id=90635 -- Alexandr Ciornii, http://chorny.net
Download (untitled) / with headers
text/plain 226b
On Fri Dec 27 18:32:06 2013, CHORNY wrote: Show quoted text
> This is due to change in DBD::SQLite. Patch is here
==== But that was to allow a 2nd call of cpan w/in cpan -- you are saying that somehow excludes external lockers?... Ug...


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.