develooper Front page | perl.perl5.porters | Postings from August 2018

Re: [perl #133440] binaries mismatched again

Thread Previous | Thread Next
From:
frederik
Date:
August 11, 2018 04:59
Subject:
Re: [perl #133440] binaries mismatched again
Message ID:
31972_1533963576_5B6E6D2F_31972_43_1_20180811042305.GB19208@ofb.net
> The immediate problem is that you have version-specific stuff stored
> in a non-version-specific directory.  That is, looking at your @INC,
> you have "locally" installed modules  in
> 
> >     /home/frederik/.local/lib/perl5/x86_64-linux-thread-multi
> 
> Perl's configuration defaults are to store version-specific stuff in
> version-specific directories.  Lots more details are in the INSTALL file,
> under the section "Coexistence with earlier versions of perl 5".
> 
> I'm not sure why you have Compress::Raw::Zlib installed locally, since
> it has been bundled with perl since version 5.9.4.  Of course you are
> certainly welcome to install different versions than those bundled with
> perl, but if you are going to do so, and if you're going to store them in
> a non-version-specific directory, you'll need to recompile them when
> you upgrade to a new major version.  Upgrade time is also a good time
> to re-visit the question of whether you want to continue overriding the
> standard version with your own local version.
> 
> Hope that helps a little,

Thank you, it does. I already know a bit about the technical reason
for the problem. Perhaps I installed something that depended on
Compress::Raw::Zlib over 10 years ago, then that module ended up in a
list of modules that I think I need to run various personal scripts
and this is why I have it installed locally. What's this about INSTALL
and version-specific directories? Did I configure things wrong when I
set up cpanm?

I guess I'm wondering why more people aren't coming to you with
questions about this. And why not change the error message to point to
a manual page which explains what to do. By "discoverability" I meant,
a way for users to understand what they're seeing by reading the
documentation that logically presents itself, for instance, if a
module author says "you can install my module using the cpan tool",
then two years later the user gets this error message, what is he
expected to do next, given lack of omniscience - i.e. only knowing
what he had to know to install cpan, and knowing the text of the error
message.

Reading what you wrote, I downloaded 'perl' and looked at INSTALL, at
all the lines containing 'version.*directory' (I didn't have time to
read all 3000 lines yet), and it didn't really answer my question. But
this is not something I think most users would be expected to do; what
happens is you get Perl from your distro and then you see there is a
module in CPAN but not in the distro, so you install it locally using
cpanm, etc. Then things break.

I would like you to say, "Frederick, here is where you went wrong, you
made a mistake that other users are not making when you did X".
Because that would explain why you haven't been getting other bug
reports about this. Lacking such an explanation, I'm kind of fearful
that the answer is that Perl has just become a tool of an older
generation of power users, many young programmers these days haven't
even heard of it, they use bland corporate languages with fewer
"gotchas"... (I'm only guessing here, because I don't use them
myself...) But maybe that's off-topic.

By the way I think I set up cpanm entirely by adding lines from `perl
-Mlocal::lib=.local` to my shell profile.

Best wishes,

Frederick

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