develooper Front page | perl.perl5.porters | Postings from July 2001

RE: CPAN packaging.

Thread Previous | Thread Next
Redford, John
July 21, 2001 10:41
RE: CPAN packaging.
Message ID:
I think you should accept option 3: Go download and install the library


The libraries might be distributed under different licensing than the Perl
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.

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

 -----Original Message-----
From: 	Marc W. Mengel [] 

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
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 and download and install it now."
is a real incompatability.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About