The ebuild for dev-perl/POE versionsnumber doesn't use versionnumber from upstream, but put an extra dot in the number Upstream POE-0.9989 portage POE-0.99.89 So when using g-cpan to create overlay ebuild for POE::Components the POE version in these ebuilds is nowhere to be found in portage. emerge: there are no ebuilds to satisfy ">=dev-perl/POE-0.9989". (dependency required by "perl-gcpan/POE-Component-Jabber-2.01" Reproducible: Always
This is done intentionally because upstream is not consistent with the version number scheme - which confuses portage. If we followed upstream for POE (or any other package where we had to do this), versions like 0.3203 would always trump later version of lesser digits, like 0.38 (to reference older POE ebuilds for illustration). Portage strips the decimal and sees that 3203 >38, and so upgrades would never be possible until 0.3801 (fictional version number) came out. We also do this for modules like module-build, which uses the expanded version numbers for mini-releases. The fact of the matter is no two upstream CPAN authors use the same versioning scheme for numbers. Some use the extended numbers for pre-releases, some for updated releases, but to a fault they flip flop on the number of integers past the decimal point. Since CPAN module versions are one of the only place that you see this aberrant behavior, I would not expect to see any updates to portage to adjust for it. The version number on the ebuild doesn't affect the $VERSION recorded in the module, and portage related tools like g-cpan know how to compare and reinterpret those numbers. If you are running CPAN by hand, it can see that you have 0.9989 installed, so other than your preference I don't see where this is relevant. Sorry for the long dissertation, this issue gets me riled :)
> [...] The version number > on the ebuild doesn't affect the $VERSION recorded in the module, and portage > related tools like g-cpan know how to compare and reinterpret those numbers. If > you are running CPAN by hand, it can see that you have 0.9989 installed, so > other than your preference I don't see where this is relevant. > But I try to install with g-cpan. The output I put in the report is from g-cpan. So apparently g-cpan doesn't know how to reinterpret the version, or I don't know how to run g-cpan. Output again: # g-cpan -i POE::Component::Jabber CPAN: Storable loaded ok Going to read /root/.cpan/Metadata Database was generated on Wed, 11 Jul 2007 06:50:47 GMT * g-cpan: Ebuild already exists for POE-Component-Jabber Calculating dependencies | emerge: there are no ebuilds to satisfy ">=dev-perl/POE-0.9989". (dependency required by "perl-gcpan/POE-Filter-XML-0.33" [ebuild]) and # perl -MPOE -e 'print $POE::VERSION' 0.9989
which version of g-cpan are you using? -0.15 is about to go stable.
(In reply to comment #3) > which version of g-cpan are you using? -0.15 is about to go stable. > I tested with g-cpan-0.15-0-r1 and g-cpan still not recognize the VERSION of POE. No big deal, I install the POE::Components by hand/CPAN. Would be nice if g-cpan could handle it though (it's not me doing anything stupid?).
> I tested with g-cpan-0.15-0-r1 and g-cpan still not recognize the VERSION of > POE. My bad. I regenerated the ebuilds and g-cpan-0.15 doesn't include a version for POE, so now it works.
(In reply to comment #5) > My bad. > I regenerated the ebuilds and g-cpan-0.15 doesn't include a version for POE, so > now it works. > Good to hear :) FWIW, I do have a bug open for g-cpan-0.15-r1 to be marked stable on all platforms - amd64, sparc, and ppc64 are done already (I realize that probably doesn't help you any, but its a start). Thanks for your patience, Mike
