Re^5: Architecture-specific module conflicts under perlbrew

[karlgoethebier]

"I posted that as an example of things generally going wrong, rather than as a specific glitch to overcome."

This is, cautiously said: a "funny approach". Isn't PM (partly) about "overcoming glitches"?

When i discovered perlbrew, i thought this is heaven-sent. But i'm skeptical about "this is the promised land" stuff.

So i installed it on different boxes, played around with it, tried to break it, did some insane things.

But it didn't break. It worked.

So i recommended it for a box that is a good part of my job. The box is for monitoring more than 120 hosts with more than 1000 services.

Setup and testing lasted about 3 month. And many people are relying on this box. And i recommended the tool on PM.

So, if someone comes and says: "That stuff you recommend doesn't work as expected!" the bells ring.

I try to understand why and how to find a solution.

If i where you (assuming you are still interested in using perlbrew) i would throw away that whole stuff and start over again with a fresh setup, doing it exactly as described in the docs.

If you can reproduce the issue, contact the author. I'm shure you get help - many rely upon perlbrew.

Best regards, Karl

P.S.: Ever had a broken Perl? No? So you are lucky. I had it one time on a Mac OS X server.

I fired up cpan and went for lunch or so.

When i was back, i had another Perl installed, tons of modules uninstalled and tons of modules new installed.

The box was unuseable - and it was not for testing purposes.

[tye]

Just because you didn't experience a problem, that doesn't mean it isn't a real problem that other people can experience (and have experienced).

Pointing out a problem with a tool is not the same as declaring that the tool is completely useless and nobody should ever use it. Or something crazy like declaring that anybody who ever decided to use it was an idiot for doing so.

I'm glad you had good experience with perlbrew. How many servers touch some install of perlbrew of yours seems completely pointless in relation to the problem that was found with perlbrew.

It is like you are trying to prevent perlbrew from getting its feelings hurt. Or that you got your feelings hurt.

I only spent a few minutes looking around when gnosti mentioned this problem and that convinced me that perlbrew really did have a serious problem with this specific case. And I realized that the fix is unlikely to be simple and that part of the problem is some fundamental problems with Perl. And I was also struck that the particulars of the problem ran rather directly into the face of the stated purpose of perlbrew and appreciated the irony of that.

Of course, none of that contradicts with the fact of people being able to use perlbrew and never experience this problem and, of course, finding great benefit from features of perlbrew.

Note that I also agreed with brian d foy's advice to never share install directories between versions of Perl, at least mostly. And I didn't read it as brian declaring that nobody should use perlbrew. He just said that he doesn't use perlbrew (despite gnosti's over-simplified summary and it being in quotes).

I bet you can even install XS-using modules when using both local::lib and perlbrew and still not run into this problem. You'd have to only install configurations of Perl where it puts the "arch" directory fully nested under both the Perl (binary interface) version string and the "arch" string (and in a way that works with local::lib's choices) -- or just get lucky like by never hitting conflicting "arch" strings. And you might have to avoid weird cases like installing two instances of the same version of Perl using different configuration choices that break binary compatibility but don't change the "arch" string (if such is possible). And you'd have to install the module multiple times (and always the same version of it), overwriting the non-arch bits repeatedly.

And, of course, you won't run into this problem if you use perlbrew w/o local::lib or with local::lib but only installing pure-Perl modules. This is something that should be clearly mentioned in the parts of the perlbrew documentation that discuss local::lib.

But I get the impression that gnosti plans to do much more than that, to actually help get perlbrew to support making it easier to install XS modules when using local::lib without running into such conflicts. Even to make it hard to not notice when you are doing something that is going cause such conflicts.

Hmm, in this particular case, I think it'd make more sense to install even the pure-Perl parts of XS-using modules under the "arch" directory tree. That isn't how Perl module install tools are supposed to do it. But that might have to be fixed at the core level and in the installers, not in local::lib nor perlbrew. And it'd be a good fix, even beyond this particular case, IMHO.

[karlgoethebier]

«It is like you are trying to prevent perlbrew from getting its feelings hurt. Or that you got your feelings hurt»

This is true.

I need a while to think about. Best regards, Karl

PS.: Where does this come from?

perl -M JSON::XS -e 1
Perl API version v5.14.0 of JSON::XS does not match v5.16.0 at /home/j
+roth/perl5/perlbrew/perls/perl-5.16.3/lib/5.16.3/XSLoader.pm line 92.
Compilation failed in require.
BEGIN failed--compilation aborted.

[gnosti]

Hey Tye,

I appreciate your thoughts on this. I wasn't actually attempting to use local::lib under perlbrew. What I think happened was I had deleted local::lib's environment settings from my .bashrc, yet ended up working in a terminal that still had PERL5LIB set.

Perlbrew might behave more consistently it if checks the user's environment and outputs some warnings of potentially problematic configurations.