The current versioning of the POE 0.95.00 package conflicts with the CPAN version numbering for POE which follows a 0.9500 version number, this causes g_cpan to fail to update cpan packages depending on POE 0.9500 because no suitable version of POE is found.
Errors encountered because of this version alteration decision include (but may not be limited to) : Calculating dependencies - emerge: there are no ebuilds to satisfy ">=dev-perl/POE-0.9500". (dependency required by "perl-gcpan/POE-Filter-IRCD-2.2" [ebuild]) Calculating dependencies \ emerge: there are no ebuilds to satisfy ">=dev-perl/POE-0.9500". (dependency required by "perl-gcpan/POE-Filter-IRCD-2.2" [ebuild])
I'm wondering here (for the sake of clarifying how this kind of problem would be introduced) why there needed to be a version number different from what CPAN reports for a package. Was upstream originally using a 0.00.00 scheme, then switching to a 0.0000 scheme? Also, inquiring so I might offer assistance (an amd 64 guinea pig) or any targeted information that might be helpful to the perl herd. A good cpan module (not yet added to portage) that depends on POE would be perl-gcpan/POE-Component-Client-Ping not terribly large or full of tests.
As a workaround (don't know how long this will suit my needs) I was able to merely copy the POE-0.95.00.ebuild to POE-0.9500.ebuild. This was done in my /usr/local/portage/ overlay. Followed by running 'ebuild -manifest POE-0.9500.ebuild' and 'ebuild -digest POE-0.9500.ebuild' within my overlay. After this I was able to: # g-cpan -i POE::Component::Client::Ping resulting in a usable POE component module installed by g-cpan as well! Leads me to think that the necessity of the versionator mumbo-jumbo was rather non-necessitous.
This is more a bug in g-cpan than in the work arounds between CPAN contributer's using a mishmash of numbering schemes for the same dist, and portage's not being able to always correctly interpret version as greater than another (because 0.32 isn't always folllowed by 0.33, but instead by 0.32001 then by 0.32002 then by 0.33, which is a portage 'bug' seemingly unique to dealing with cpan packages). Let me see if I can work a solution into g-cpan instead.
g-cpan-0.15_rc1 is in the tree and contains fixes that cover this bug.
