Project:Perl/g-cpan

Intro
is a tool that generates and installs perl modules and bundles from CPAN "on-the-fly." It was originally proposed on the gentoo-user mailing list and filed as.

CPAN Configuration
When you run g-cpan, it will check for two configuration files. If you are root, it will check for the presense of an already configured CPAN under your perl install path. If CPAN is not configured, or you are not root, g-cpan will create a generic configuration for CPAN in ~/.cpan/CPAN/ called MyConfig.pm. You can modify this file as needed at any time.

The CPAN configuration file is used for interacting with CPAN, determining what modules are available, what modules are needed, and performing all basic CPAN functions.

Versions of g-cpan prior to 0.14 performed all of the CPAN related work in ~/.cpan. As of 0.14, the downloading and exploration of the CPAN module for dependency information is stored in /var/tmp/g-cpan. This directory can be directly modified in the appropriate MyConfig.pm

g-cpan and Overlays
g-cpan is overlay "friendly." g-cpan will scan both the overlays provided in your make.conf as well as any you have set via environment variables, to help determine its course of action. If you have defined overlays, g-cpan will use the first overlay in your list that the user running it can write to. Any ebuilds generated by g-cpan will be stored in this overlay for future use (such as upgrading).

If no overlays are defined, or the user operating g-cpan cannot write to an overlay, then anything generated will be written to a temporary space and wiped on exit. Without an overlay to write to, certain functions will not be available, such as upgrading.

Caveats

 * g-cpan relies on your ACCEPT_KEYWORDS to generate ebuilds that your system will install. If you haven't set your ACCEPT_KEYWORDS in /etc/make.conf, it will default to the complete list of supported architectures when generating an ebuild. At this time, however, g-cpan cannot check the KEYWORDS for the ebuilds in portage that your requested module must depend on. It is therefore possible to generate ebuilds that you cannot emerge because the depending modules are not keyworded or unmasked for your architecture.


 * g-cpan has no way of handling truly interactive module installs. In the regular portage tree, that is something we work around with patches and sed statements. g-cpan does not have this luxury and may hang on an interactive module install.


 * g-cpan isn't going to know about any special environment variables or library paths that may be necessary to compile a particular module, for instance a module depending on database library paths. The best advise for this is to use the --generate option and modify the resulting ebuild yourself.