On 11/25/2014 10:41 AM, Andreas K. Huettel wrote:
>>> You could check (before running emerge) if you see the "3.2.10" anywhere
>>> in
>>> your environment ("set|less")... or if maybe $PV or $S is set outside
>>> emerge somewhere.
>> Wow, incredible. I never thought to check my environment, but these:
>>
>> MODULE_VERSION=3.2.10
>> MODULE_VERSION_STACK=3.2.10
>>
> :)
>
> Yes. It's MODULE_VERSION, which is used in perl-module.eclass.
>
>> This was also affecting dev-libs/stfl for me; unsetting MODULE_VERSION
>> causes this to succeed.
> It can in principle affect many things inheriting perl-module.eclass, I'll
> check later what these two do different.
>
> The best workaround is probably to make a short script wrapper for emerge
> that
> unsets the variables and then calls real emerge. A real fix would be to
> rename
> the variable in the eclass, but that would mean fixing 1800 ebuilds...
>
Yes, I will just remember to do this every time I update. Not a problem.
>> Andreas, if this is a bug that needs fixing, let me know who to contact
>> get this dealt with.
> I'm probably the best address myself, but there is no easy solution. I'll
> think about it.
>
> Cheers,
> Andreas
>
Don't worry about it too much; modules is a pretty exotic package,
mostly used in super-computing sites afaik. I am just wondering, though,
why aren't all internal variables prefixed with PORTAGE_ or the like to
prevent this sort of thing?
Thank you for the help,
Alec
