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)

History Show all quoted text
  Wed Dec 25 02:56:33 2013 pause [...] tlinx.org - Ticket created
Subject: install of SQlite prevents parallel cpan builds due to locking
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
  Thu Dec 26 15:37:32 2013 bdfoy [...] cpan.org - Correspondence added
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>
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`.
  Thu Dec 26 15:37:33 2013 The RT System itself - Status changed from 'new' to 'open'
  Thu Dec 26 15:49:55 2013 pause [...] tlinx.org - Correspondence added
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?
  Fri Dec 27 18:32:06 2013 CHORNY [...] cpan.org - Correspondence added
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
  Fri Dec 27 18:32:29 2013 CHORNY [...] cpan.org - Cc CHORNY added
  Fri Dec 27 18:55:17 2013 pause [...] tlinx.org - Correspondence added
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...