On Tue, Jan 19, 2010 at 9:40 AM, Iain Arnell wrote:
>
> I'm not sure where it should be fixed, but the bad behaviour of
> Module::Install::Share seems to be the result of a change to EU::MM.
> In F12, perl-ExtUtils-MakeMaker-6.36-87.fc12.x86_64, generated
> Makefiles contain things like
>
> pure_s
On Mon, Jan 18, 2010 at 12:36 AM, Chris Weyl wrote:
> On Fri, Jan 15, 2010 at 5:33 PM, Stepan Kasal wrote:
[ and some time before that, Chris wrote: ]
>>> Not to put too fine a point on it, is this intentional? :) It appears
>>> to be playing havoc with install_share / Module::Install::Share (hen
On Fri, Jan 15, 2010 at 5:33 PM, Stepan Kasal wrote:
>> I noticed that %perl_vendorlib was evaluating to /usr/share/perl5.
>
> it is definitely intentional, part of the long-planned @INC cleanup.
Gotcha.
>> Checking out devel/perl.spec I see it defined this way as well;
>> unversioned, and undif
Hello,
> I noticed that %perl_vendorlib was evaluating to /usr/share/perl5.
it is definitely intentional, part of the long-planned @INC cleanup.
> Checking out devel/perl.spec I see it defined this way as well;
> unversioned, and undifferentiated from core.
Yes, it is unversioned. Modules buil
Hey all --
So, I was looking into a FTBFS report on perl-SQL-Translator[1], when
I noticed that %perl_vendorlib was evaluating to /usr/share/perl5.
Checking out devel/perl.spec I see it defined this way as well;
unversioned, and undifferentiated from core.
Not to put too fine a point on it, is th
