Skip Menu |
 

This queue is for tickets about the Perl-Dist-Strawberry CPAN distribution.

Report information
The Basics
Id: 50283
Status: rejected
Priority: 0/
Queue: Perl-Dist-Strawberry

People
Owner: Nobody in particular
Requestors: kmx [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Oct2009-beta2 - core/vendor/site issue (maybe)
Hi, I have perhaps more a question than a bug concerning the newly introduced core/vendor/site concept. 1) Let us have a clean strawberry 5.8.9 Oct2009-beta2 installation - with the following dirs: c:\strawberry\perl\lib c:\strawberry\perl\vendor c:\strawberry\perl\site 2) In "core" subdir (c:\strawberry\perl\lib) we have for example the package Test::Simple (v0.94) 3) For whatever reason I want to install another version of Test::Simple - e.g. I want to have a version 0.92 instead of 0.94 included in strawberry relese - so I simply run: c:\> cpan -i MSCHWERN/Test-Simple-0.92.tar.gz 4) What I expect is that the newly installed Test-Simple-0.92 will go to c:\strawberry\perl\site directory - and as c:\strawberry\perl\site\lib is in @INC before c:\strawberry\perl\lib - my 0.92 (in site) will have a precedence before 0.94 (in core) - HOWEVER IT INSTALLS TO c:\strawberry\perl\lib My questions are: - is the behaviour described above correct and intentional? - if "yes" I have serious doubts what are the wins of core/vendor/site concept (and you can reject this RT) -- kmx
Download (untitled) / with headers
text/plain 574b
You have a good question... (Un)Fortunately, a lot of the dual-life modules (but not all) have code like this, in order to get around the previously broken order: http://cpansearch.perl.org/src/MSCHWERN/Test-Simple-0.94/Makefile.PL: #... # Added to the core in 5.7.3 and also 5.6.2. INSTALLDIRS => $] >= 5.006002 ? 'perl' : 'site', #... so that you have to be specific in adding the appropriate command line parameter in order to install a dual-life module into site. That means that I have to reject this, saying that it's intended by the module author, OK?
Subject: Re: [rt.cpan.org #50283] Oct2009-beta2 - core/vendor/site issue (maybe)
Date: Wed, 07 Oct 2009 16:53:31 +0200
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 851b
Curtis Jewell via RT napsal(a): Show quoted text
> That means that I have to reject this, saying that it's intended by the > module author, OK?
I am not against rejecting it for now - we probably cannot do much about that.. But the question is who is a decision-maker when installing a module via "cpan -i Module::Name" on my computer 1) the module author? (he wants "core") 2) or me? (I want "site") With the new core/vendor/site approach I would expect that directories "core" + "vendor" could be lock (=made ReadOnly) after strawberry installation. That is not currently possible. I simply do not see the benefits of new core/vendor/site system (maybe they come in future :). According to http://use.perl.org/~schwern/journal/39246 - The CPAN shell should be using INSTALLDIRS=site - Nothing should be using perl/core. Can I ask Alias for his opinion? -- kmx
Subject: Re: [rt.cpan.org #50283] Oct2009-beta2 - core/vendor/site issue (maybe)
Date: Thu, 8 Oct 2009 10:58:47 +1100
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: Adam Kennedy <adamkennedybackup [...] gmail.com>
Download (untitled) / with headers
text/plain 1.4k
It is currently intentional, pretty much all modules (even site) are locked readonly so that isn't a problem. I do see the problem though, we'll need to take the issue up with p5p. This problem is being solved (properly) in 5.11 at the moment, the fact we're going a bit early may raise some issues. We probably need to coordinate with p5p on how we should solve this. Adam K 2009/10/8 kmx via RT <bug-Perl-Dist-Strawberry@rt.cpan.org>: Show quoted text
>       Queue: Perl-Dist-Strawberry >  Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=50283 > > > Curtis Jewell via RT napsal(a):
>> That means that I have to reject this, saying that it's intended by the >> module author, OK?
> I am not against rejecting it for now - we probably cannot do much about > that.. > > But the question is who is a decision-maker when installing a module via > "cpan -i Module::Name" on my computer > 1) the module author? (he wants "core") > 2) or me? (I want "site") > > With the new core/vendor/site approach I would expect that directories > "core" + "vendor" could be lock (=made ReadOnly) after strawberry > installation. That is not currently possible. I simply do not see the > benefits of new core/vendor/site system (maybe they come in future :). > > According to http://use.perl.org/~schwern/journal/39246 > - The CPAN shell should be using INSTALLDIRS=site > - Nothing should be using perl/core. > > Can I ask Alias for his opinion? > > -- > kmx > > >
Download (untitled) / with headers
text/plain 619b
On Wed Oct 07 19:59:06 2009, adam@ali.as wrote: Show quoted text
> It is currently intentional, pretty much all modules (even site) are > locked readonly so that isn't a problem. > > I do see the problem though, we'll need to take the issue up with p5p. > This problem is being solved (properly) in 5.11 at the moment, the > fact we're going a bit early may raise some issues. We probably need > to coordinate with p5p on how we should solve this. > > Adam K
I get the feeling that CPAN/CPANPLUS.pm flips the readonly bit, and unflips it when doing an upgrade. Should the default configurations specify INSTALLDIRS=site ? --Curtis
I have a question regarning Strawberry 5.12 + core/vendor/site

When I try to install some dual live module (let us say "Encode") via: "cpan -fi Encode" I expect that this modules will be installed into perl\site\lib + perl\site\bin - however as far as what I see on my strawberry 5.12 installation it is not.

It would be nice to somehow assure (if possible at all) that all modules installed by user on top of strawberry release will go to perl\site\lib + perl\site\bin.

--
kmx



This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.