Inconsistant behavior when using @ version numbers and already installed modules #229

Closed
jonathanq opened this Issue Apr 5, 2013 · 4 comments

Projects

None yet

2 participants

@jonathanq

I came across some interesting behaivor and I am not sure if it is expected or not. This is Perl 5.10.1 on CentOS 6 incase that matters.

When I install a module:

[vagrant@legacy-berkshelf ~]$ cpanm DBI@1.625
--> Working on DBI
Fetching http://www.cpan.org/authors/id/T/TI/TIMB/DBI-1.625.tar.gz ... OK
Configuring DBI-1.625 ... OK
Building and testing DBI-1.625 ... OK
Successfully installed DBI-1.625
1 distribution installed
[vagrant@legacy-berkshelf ~]$

And then re-run the command - I would expect it to tell me its already installed. Instead cpanm re-installs it:

[vagrant@legacy-berkshelf ~]$ cpanm DBI@1.625
--> Working on DBI
Fetching http://www.cpan.org/authors/id/T/TI/TIMB/DBI-1.625.tar.gz ... OK
Configuring DBI-1.625 ... OK
Building and testing DBI-1.625 ... OK
Successfully installed DBI-1.625
1 distribution installed
[vagrant@legacy-berkshelf ~]$

However if I remove the @ version - it does what I expect and bails out right away saying its installed:

[vagrant@legacy-berkshelf ~]$ cpanm DBI
DBI is up to date. (1.625)
[vagrant@legacy-berkshelf ~]$

I tried the --skip-satisified flag and then it did what I expected when I tried to re-install the module using the @ version - it told me it was already installed.

[vagrant@legacy-berkshelf ~]$ cpanm DBI@1.625 --skip-satisfied
You have DBI (1.625)
[vagrant@legacy-berkshelf ~]$

Seems to me that you should be able to run cpanm DBI@1.625 and have it do a no-op if the module at that version is already installed.

EDIT The issue with HTML::Entities version 3.69/3.70 I originally included is a problem with the module itself, it is listed on http://www.cpan.org/modules/02packages.details.txt as 3.69 with the .tar.gz file being 3.70. I tested the upgrade of an already installed module and it succeeded fine for different cpan modules. So no issue there - updated the github issue and title to reflect.

@miyagawa
Owner
miyagawa commented Apr 5, 2013

Since you updated the bug (yes, HTML::Entities latest is 3.69 not 3.70) i don't see what is an issue now.

Seems to me that you should be able to run cpanm DBI@1.625 and have it do a no-op if the module at that version is already installed.

You can do that with @ version and --skip-satisfied, no?

@jonathanq

My confusion is why running:
cpanm DBI - results in cpanm reporting the latest version is installed
cpanm DBI@1.625 - results in cpanm re-installing the module (when version 1.625 is already installed).

Given the other issue is module problem - and I can use --skip-satisfied - I am happy to close this. The behavior just seems odd to me that taking off the @ version causes it to check the installed version. But specifying the version requires you to add the --skip-satisfied flag to get the same result.

@jonathanq

I'm going to close this - as you pointed out, with the use of --skip-satisfied - the desired behavior is achieved, so this is more just a misunderstanding of how cpanm should have worked given the different methods of calling it.

Thanks!

@jonathanq jonathanq closed this Apr 8, 2013
@miyagawa
Owner
miyagawa commented Apr 8, 2013

Well, you're right that the behavior could be argued as slightly inconsistent between @ver and ver. You can leave it open and I will take a look although there's a workaround with skip-satisfied. 

Sent from Mailbox for iPhone

On Mon, Apr 8, 2013 at 9:07 AM, Jonathan Quail notifications@github.com
wrote:

I'm going to close this - as you pointed out, with the use of --skip-satisfied - the desired behavior is achieved, so this is more just a misunderstanding of how cpanm should have worked given the different methods of calling it.

Thanks!

Reply to this email directly or view it on GitHub:
#229 (comment)

@miyagawa miyagawa reopened this Apr 8, 2013
@miyagawa miyagawa added a commit that closed this issue Apr 14, 2013
@miyagawa with --skip-installed (by default), check if the version it's about t…
…o install is already installed. Fix #229
d167f40
@miyagawa miyagawa closed this in d167f40 Apr 14, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment