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