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
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!!
*** 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.