Skip Menu |

This queue is for tickets about the CPANPLUS CPAN distribution.

Report information
The Basics
Id: 26914
Status: resolved
Priority: 0/
Queue: CPANPLUS

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

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



Subject: CPANPLUS depending on Crypt::OpenPGP even when gpg is available.
For some reason CPANPLUS is depending on Crypt::OpenPGP on my OS X machine. I do not have Crypt::OpenPGP installed and its a rather complex module to install, it would be best if CPANPLUS didn't depend on it. I have a working gpg. $ perl -MIPC::Cmd=can_run -wle 'print can_run("gpg")' /opt/local/bin/gpg As the CPANPLUS dependency list is generated I'm not sure where to look to figure out what's gone wrong.
Subject: Re: [rt.cpan.org #26913] CPANPLUS depending on Crypt::OpenPGP even when gpg is available.
Date: Thu, 3 May 2007 12:27:32 +0200
To: bug-CPANPLUS [...] rt.cpan.org
From: "Jos I. Boumans" <kane [...] dwim.org>
On 03 May 2007, at 12:21, Michael G Schwern via RT wrote: Show quoted text
> > Thu May 03 06:19:47 2007: Request 26913 was acted upon. > Transaction: Ticket created by MSCHWERN > Queue: CPANPLUS > Subject: CPANPLUS depending on Crypt::OpenPGP even when gpg is > available. > Broken in: 0.78 > Severity: Important > Owner: Nobody > Requestors: MSCHWERN@cpan.org > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=26913 > > > > For some reason CPANPLUS is depending on Crypt::OpenPGP on my OS X > machine. I do not have Crypt::OpenPGP installed and its a rather > complex module to install, it would be best if CPANPLUS didn't > depend on > it. I have a working gpg. > > $ perl -MIPC::Cmd=can_run -wle 'print can_run("gpg")' > /opt/local/bin/gpg > > As the CPANPLUS dependency list is generated I'm not sure where to > look > to figure out what's gone wrong.
take a look at CPANPLUS::Selfupdate, around line 134. There it figures out what dependencies are needed for signatures. It holds code like: sub { my $cb = shift; return if can_run('gpg') and $cb->configure_object->get_conf('prefer_bin'); return { 'Crypt::OpenPGP' => '0.0' }; }, It basically says 'since you dont prefer /bin/gpg but would like signatures, you should install crypt::openpgp'... in reality, if you dont install the crypt module, it'll just mention you dont have it, and fall back to gpg.. Any suggestions on improving the heuristics (and that's all they are), are welcome... -- Jos
Subject: CPANPLUS depending on Crypt::OpenPGP even when gpg is available.
For some reason CPANPLUS is depending on Crypt::OpenPGP on my OS X machine. I do not have Crypt::OpenPGP installed and its a rather complex module to install, it would be best if CPANPLUS didn't depend on it. I have a working gpg. $ perl -MIPC::Cmd=can_run -wle 'print can_run("gpg")' /opt/local/bin/gpg As the CPANPLUS dependency list is generated I'm not sure where to look to figure out what's gone wrong.
Subject: CPANPLUS depending on Crypt::OpenPGP even when gpg is available.
For some reason CPANPLUS is depending on Crypt::OpenPGP on my OS X machine. I do not have Crypt::OpenPGP installed and its a rather complex module to install, it would be best if CPANPLUS didn't depend on it. I have a working gpg. $ perl -MIPC::Cmd=can_run -wle 'print can_run("gpg")' /opt/local/bin/gpg As the CPANPLUS dependency list is generated I'm not sure where to look to figure out what's gone wrong.
Subject: Re: [rt.cpan.org #26913] CPANPLUS depending on Crypt::OpenPGP even when gpg is available.
Date: Fri, 04 May 2007 05:09:53 -0700
To: bug-CPANPLUS [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
kane@dwim.org via RT wrote: Show quoted text
> take a look at CPANPLUS::Selfupdate, around line 134. There it > figures out > what dependencies are needed for signatures. It holds code like: > > sub { > my $cb = shift; > return if can_run('gpg') and > $cb->configure_object->get_conf('prefer_bin'); > return { 'Crypt::OpenPGP' => '0.0' }; > }, > > It basically says 'since you dont prefer /bin/gpg but would like > signatures, > you should install crypt::openpgp'... in reality, if you dont install > the > crypt module, it'll just mention you dont have it, and fall back to > gpg..
Problem with that is the automated installation of CPANPLUS means it tries to install Crypt::OpenPGP which leads down a long road of compiling dependent XS modules which often don't work leading to the CPANPLUS installation failing. Right now Math::Pari and Crypt::RSA are haven't issues for me. I also had a look at my prefer_bin setting. Its the default of: 'prefer_bin' => (eval {require Compress::Zlib; 1}?0:1) which seems a bit of an odd way to do it though I guess its as good as any. Show quoted text
> Any suggestions on improving the heuristics (and that's all they > are), are welcome...
If Crypt::OpenPGP is not available, and gpg is, just use gpg. Crypt::OpenPGP is too complex to install. Come to think of it, can't Module::Signature handle signatures? I haven't looked any deeper but it smells like a wheel is being reinvented.
Subject: Re: [rt.cpan.org #26913] CPANPLUS depending on Crypt::OpenPGP even when gpg is available.
Date: Fri, 4 May 2007 14:33:32 +0200
To: bug-CPANPLUS [...] rt.cpan.org
From: "Jos I. Boumans" <kane [...] xs4all.nl>
On 04 May 2007, at 14:14, Michael G Schwern via RT wrote: Show quoted text
> > Problem with that is the automated installation of CPANPLUS means > it tries to > install Crypt::OpenPGP which leads down a long road of compiling > dependent XS > modules which often don't work leading to the CPANPLUS installation > failing.
Understood. In this case, Crypt::OpenPGP is actually optional (but there's no good way to express that). The reason it's required is of these reasons: * your conf setting 'signature' is true. This is because you have 'gpg' or 'Crypt::OpenPGP' installed (default config heuristic), or enabled it explicitly at some point. * Because your 'prefer_bin' setting is false (again, heuristic or disabled exlicitly) we list the perl module as a prereq. Logically, this all makes sense. However arguably this is much more pain than it's worth. Show quoted text
> If Crypt::OpenPGP is not available, and gpg is, just use gpg. > Crypt::OpenPGP > is too complex to install.
Agreed. Even though it's not in line with the rest of the heuristics, the change you propose is probably far less painful. The worst that can happen when we make this change is that you get a warning that you should install Crypt::OpenPGP, it falls back to gpg and stuff keeps working anyway. Show quoted text
> Come to think of it, can't Module::Signature handle signatures? I > haven't > looked any deeper but it smells like a wheel is being reinvented.
Not really. We use Module::Signature and /it/ in turn wants gpg or Crypt::OpenPGP. We're basically making sure it works out without needing to invoke it's hackery-pokery Makefile.PL/Module::AutoInstall stuff. Take a peek: http://search.cpan.org/src/AUDREYT/Module-Signature-0.55/Makefile.PL Thanks for your feedback, -- Jos I. Boumans RIPE Network Coordination Center Database Group Manager Singel 258 Amsterdam NL http://www.ripe.net +31 20 535 4444
Subject: Re: [rt.cpan.org #26914] Re: [rt.cpan.org #26913] CPANPLUS depending on Crypt::OpenPGP even when gpg is available.
Date: Fri, 04 May 2007 16:19:02 -0700
To: bug-CPANPLUS [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
kane@xs4all.nl via RT wrote: Show quoted text
>> Come to think of it, can't Module::Signature handle signatures? I >> haven't >> looked any deeper but it smells like a wheel is being reinvented.
> > Not really. We use Module::Signature and /it/ in turn wants gpg or > Crypt::OpenPGP. We're basically making sure it works out without > needing to > invoke it's hackery-pokery Makefile.PL/Module::AutoInstall stuff. > > Take a peek: > http://search.cpan.org/src/AUDREYT/Module-Signature-0.55/Makefile.PL
You're replacing its hackery-pokery with your own hackery-pokery? Why do you need to make sure a dependent module has its own dependencies working? Why are you side-stepping its install process? Shouldn't it Just Work? If it doesn't, shouldn't the dependency be fixed instead of the problem oozing into CPANPLUS (and anyone else)? I really think this is a problem you should leave in the hands of another module to reduce the complexity and responsibilities of CPANPLUS. Take the hard problem. Put it in a box. Hand it to Audrey. :)