search

gflohr / libintl-perl

Official repository for libintl-perl
http://www.guido-flohr.net/en/projects/#libintl-perl
GNU General Public License v3.0
5 stars 4 forks source link

Cannot use libintl-perl as an uninstalled library #5

Closed GavinSmith0123 closed 4 years ago

GavinSmith0123 commented 5 years ago

If a Perl program adds relative paths to @INC in order to use an uninstalled copy of libintl-perl, then some of the uninstalled modules in the library will be loaded, but some installed modules will be used too in an installed copy of libintl-perl. This is due to this change:

https://github.com/gflohr/libintl-perl/commit/74f3a35cc24a54ada3bbef96d79e63a0592b7f18

The uninstalled version of Locale::Messages will be used but it won't load an uninstalled version of Locale::gettext_pp. (This is the case in the Texinfo project after libintl-perl was upgraded to 1.31 from 1.20.)

This is not desirable behaviour, as there might not be an installed version of the module, or it might be from a different version of libintl-perl and not compatible. It is confusing when trying to track the execution of the code, when for example inserted print statements in the uninstalled code do not do anything.

Maybe one fix is to only remove '.' from @INC, and not just any relative path, as suggested at http://article.gmane.org/gmane.comp.lang.perl.perl5.porters/160507:

BEGIN { pop @INC if $INC[-1] eq '.' }

Or maybe leave it up to any program using libintl-perl to take care of the potential security problems involved in using relative paths in @INC.

gflohr commented 5 years ago

I'll have a look.

GavinSmith0123 commented 4 years ago

Any news on this?

gflohr commented 4 years ago

One solution would be to set $VERSION in every module, and then somehow require that as the minimum version (because you cannot require an exact version in Perl). That should fix the problem, too, shouldn't it?

GavinSmith0123 commented 4 years ago

Sorry, I don't see what that has to do with module search paths.

gflohr commented 4 years ago

Perl would then not consider the installed versions of libintl-perl, when the version is lower than the one of the uninstalled version.

But I am also considering your suggestion. In my opinion it kind of defeats the purpose of ignoring '.' in @INC but on the other hand I actually always meant that people that put . in their $PATH do not really deserve any protection by the software because it's downright stupid. On the other hand, having relative paths in @INC usually means that you know what you're doing.

I will solve your problem one way or other this week. Apologies again for the long delay.

GavinSmith0123 commented 4 years ago

Thanks for coming back to this issue. This seems to assume that the installed version is an older version than the uninstalled version, but the opposite is possible too.

gflohr commented 4 years ago

Should be fixed with 275b1e2.

GavinSmith0123 commented 4 years ago

Thanks, I'll give it a try. Is there a new release of libintl-perl planned soon?

gflohr commented 4 years ago

Yes, sure. I just need a free time slot. I'll try to do it tomorrow.

gflohr commented 4 years ago

And today I managed to do it. Version 1.32 is now available.