There is a need for us to be able to offer perl modules on the fly via portage so that we can 1) minimize the amount of empty ebuilds in dev-perl currently (ebuilds whose sole content is to call the perl-module eclass) and 2) minimize the need for new ebuilds in dev-perl (if we were to ebuild every perl module in cpan, for instance, we would be facing a dev-perl of a couple thousand ebuilds). Code for grabbing the perl-module lists from cpan, along with the list of mirrors, where they're at, calculating dependancies within perl, etc., is easily coded in perl. However, to integrate it with portage properly, we would need a few hooks added to emerge. Ideally, this would involve an option (-- perlmodule, for instance) that when called would call our new g-cpan app (vaporware at the moment since we need to know how it is going to be called before getting too deep into coding it - there are currently two viable alternatives in another bug report) and pass search and install requests to it. Unfortunately, I don't know enough about the internal workings of portage to know if that is enough, or if it would be better to provide a stream-line of how the process should go and then add it directly into emerge or ebuild.sh themselves. In theory, calls to g-cpan would cause the perl module and deps to be downloaded, installed, then posted as virtual/perl-module name. If this doesn't sound doable, just let me know, or if another approach would be better, I am more than open to suggestions. The goal is to offer a maximum number of perl modules via a minimal number of ebuild scripts. Thanks!! mike
*** This bug has been marked as a duplicate of 3450 ***
my bad i didnt see the reporter
Not sure what the status is on this, but so much has changed since this was originally posted, I think it's better to leave it as LATER for now.