Here's a solution to solve not the 5 -> 6 transition, but eliminate the
problem going forward: make the https dependency explicit.
That means moving LWP::Protocol::https into its own distribution that depends
on LWP. LWP::Protocol::https depends on whatever encryption stuff it needs.
Then if one *explicitly* wants LWP with https support they can depend on LWP
and LWP::Protocol::https. No more guessing which encryption modules to depend on.
On 2011.3.25 6:54 AM, Gisle_Aas via RT wrote:
Show quoted text> I'm not sure what to do about it. One option is to not state the SSL dependencies as
> recommended modules, but as PREREQ_PM directly.
That would be the best solution, I'm all for encryption being as easy as
possible, but I understand if you're hesitant to do that because of the track
record of the encryption modules.
The problem is LWP is so critical that it has to work and the encryption
modules aren't quite up to snuff.
I see you own the whole https chain now, so maybe one solution is to firm up
the encryption modules and go with it. I think this is the best solution, but
you might not want to carry that load.
Another option is to split out LWP::Protocol::HTTPS, as above, and the rest of
the code goes into LWP-HTTP or something. Then LWP depends on LWP-HTTP and
LWP::Protocol::https. So when one installs LWP they get http and https
support, but if necessary one can install just LWP-HTTP for just HTTP support.
The problem there is if someone requires LWP::UserAgent they might expect
HTTPS support as well. I don't have a solution for that.
Show quoted text> I don't like to make the dependencies be dynamic based on stuff available on the system where
> the Makefile.PL runs. This might not be the same system where the module ends up installed.
> This is for instance the case for ppm in ActivePerl.
I understand that concern. IMO vendors have the infrastructure and scale to
deal with special cases like this. Provide a --with-ssl flag to the
Makefile.PL. They can set explicitly and then they'll add that to their build
system.
Individual users are not set up to handle special cases. Each one will expect
that just installing from the CPAN shell will work.
For example, MakeMaker ships with a bunch of bundled modules in inc/. Vendors
have to know to delete inc, or have those bundled modules already installed,
before packaging MakeMaker. I'm ok with that because inc lets CPAN shell
installs work.
In short, I'm happy to make life a bit more difficult for vendors if it makes
life simpler for individual CPAN users.
Show quoted text> Mozilla::CA can be added as a PREREQ_PM dependency for libwww-perl without much pain.
> That module will always build and it does not have any other dependencies by itself. That way it
> should always be available when/if IO::Socket::SSL is installed.
That sounds like an ok solution if it works.
Show quoted text> Problem then is systems where Crypt::SSLeay is installed but not IO::Socket::SSL. These
> will start failing unless proper overrides are provided. Crypt::SSLeay can
use the
Show quoted text> certificates from Mozilla::CA but it can't do full verification of hostnames.
So if I get that straight, if the user has just Crypt::SSLeay and Mozilla::CA
there's additional fiddling with LWP flags that has to go on before it will
work? Could those flags be the default for Crypt::SSLeay?
Is there enough benefit supporting two SSL chains in the code?
--
91. I am not authorized to initiate Jihad.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
