>>>>> On Wed, 25 Jan 2006 16:40:08 -0800, Linda W <[EMAIL PROTECTED]> said:
> I'm not sure I understand the reason for the lock file
> placed in cpan_home. If I have two different architectures
> with different build directories, I'm not sure I understand
> where the conflict is -- is it in storing/listing Bundles,
> the history file, the Metafile or the shared source?
> I can understand private history, but the Bundles aren't
> updated often, the sources should be fairly static (unless
> new files are downloaded), The metafile would be updated about
> once a day (default).
> If the build directories are separate, why would there be a
> need for locking more in interactive use vs. batch use?
You're right, the lockfile locks more than strictly necessary. If you
get the current development version from my CPAN directory, you'll
find this paragraph (added in 1.83_56):
=item Lockfile
Interactive sessions maintain a lockfile, per default C<~/.cpan/.lock>
(but the directory can be configured via the C<cpan_home> config
variable). The shell is a bit picky if you try to start another CPAN
session. It dies immediately if there is a lockfile and the lock seems
to belong to a running process. In case you want to run a second shell
session, it is probably safest to maintain another directory, say
C<~/.cpan-for-X/> and a C<~/.cpan-for-X/CPAN/MyConfig.pm> that
contains the configuration options. Then you can start the second
shell with
perl -I ~/.cpan-for-X -MCPAN::MyConfig -MCPAN -e shell
How to configure the two separate MyConfig.pm files so that they share
some resources could be an interesting exercise.
I've put it into my Todo list and if you try it, please let me know
how well it goes.
--
andreas
