RE: CPAN packaging.

I think you should accept option 3: Go download and install the library
yourself.

Why?

The libraries might be distributed under different licensing than the Perl
modules.
The libraries might cost money.
Patching and upgrading the libraries should not require releasing a new Perl
module when the API does not change.
There may be multiple, compatible implementation of the library.
Some operating systems may already have the library installed.
The library install may be too complicated to perform automatically.
The installer might want to modify the library build.
Complex installation scenarios (AFS, for example) are unlikely to work
properly with arbitrary library code.
Etcetera.

Opinion: If you want everything done for you, hire a system administrator.
Expecting all technology to work automatically is unrealistic.

Disclaimer: I never use the CPAN module, because it fails utterly in my
environment.

 -----Original Message-----
From: 	Marc W. Mengel [mailto:mengel@fnal.gov] 


It seems to me that this breaks the model of CPAN, that you can install
these modules and they just work.  So it seems to me we need to either
1) make a statment that CPAN modules should include their requisite
   code libraries
 OR
2) include in CPAN a mechanism to have the URL, etc. for the source of
   a dependant library, so if it isn't present we download it and
   build it before building the module.
Or perhaps there's some third option I'm not thinking of.  But having
modules that used to work, suddenly start saying "Sorry, you need to
go to http://foo.bar.com/whatever and download and install it now."
is a real incompatability.

• CPAN packaging. by Marc W. Mengel
• RE: CPAN packaging. by Horsley Tom
• RE: CPAN packaging. by Redford, John
• Re: CPAN packaging. by Michael G Schwern