develooper Front page | perl.perl5.porters | Postings from September 2012

Re: CPAN.pm on VMS: (was Re: [Round 2] Taking CPANPLUS out of core)

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
September 30, 2012 19:04
Subject:
Re: CPAN.pm on VMS: (was Re: [Round 2] Taking CPANPLUS out of core)
Message ID:
CA+vYcVx2uDjsZ32uU_OzTrbnKdG5FE90=t96uL7ZiCMS5tM9xg@mail.gmail.com
On Sun, Sep 30, 2012 at 7:58 PM, David Golden <xdg@xdg.me> wrote:
> On Sun, Sep 30, 2012 at 10:33 AM, Craig A. Berry
> <craig.a.berry@gmail.com> wrote:
>>
>> And note that I do have write access to the Perl library directories,
>> in this case on two counts: I'm the owner of them and I'm also running
>> with privileges that give me write access to everything.  So whatever
>> it's doing to detect that is simply wrong in this environment, and
>> there are probably many such portability gotchas.
>
> Hi, Craig.  It's doing this:
>
>   sub _can_write_to_libdirs {
>       return -w $Config{installprivlib}
>           && -w $Config{installarchlib}
>           && -w $Config{installsitelib}
>           && -w $Config{installsitearch}
>   }
>
> Do some of those just wind up undefined on VMS?

Thanks for looking up how it's done.  No, they are all defined (from a
recent blead build directory):

$ search config.sh installprivlib,installarchlib,installsitelib,installsitearch
installarchlib='perl_root:[lib.VMS_IA64-thread-multi.5_17_5]'
installprivlib='perl_root:[lib]'
installsitearch='perl_root:[lib.site_perl.VMS_IA64-thread-multi]'
installsitelib='perl_root:[lib.site_perl]'

and I do have write access:

$ perl -we "use Config; print -w $Config{installprivlib};"
1
$ perl -we "use Config; print -w $Config{installarchlib};"
1
$ perl -we "use Config; print -w $Config{installsitelib};"
1
$ perl -we "use Config; print -w $Config{installsitearch};"
1

> I'm happy to try to help debug/fix CPAN.pm on VMS, even if that's just
> to skip the kind of tricky help (like boostrapping local::lib) that
> works on Unix, but I definitely would need more help figuring out the
> variances.
>
> The "can't create" appears to be a failure of File::Path::mkpath on
> the path shown in the error ("d0:[craig]/.cpan").  Clearly, the loop
> should bail out if there's a problem and that's poor.

Yeah, maybe a retry limit of 10 or something.

> Where the
> directory comes from is tricky, but my guess is that it's just
> effectively "$ENV{HOME}/.cpan".  (And, yes, I found a hardcoded "/"
> join rather than File::Spec.  Not sure if that matters.)

My guess would be that it's happening here:

$ search [.cpan.CPAN...]*.pm ".cpan"""

******************************
D0:[craig.blead.cpan.CPAN.lib.CPAN]HandleConfig.pm;1

    @dirs = map { "$_/.cpan" } grep { defined } @dirs;

Converting $_ to Unix format would be a start, though using
File::Spec->catdir($_, '.cpan') could also work, depending on what
else is going to be done with that directory specification.  Typically
we would also need to name the directory _cpan instead of .cpan
because (by default) you can't have a directory name that has a dot in
it.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About