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.
- tye
In reply to Re^6: Architecture-specific module conflicts under perlbrew (feel)
by tye
in thread Architecture-specific module conflicts under perlbrew
by gnosti
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |