| Summary: | dev-perl/POE ebuild versioning should follow upstream conventions. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Håkan Wessberg <nacka-gentoobugs> |
| Component: | New packages | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED INVALID | ||
| Severity: | minor | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Håkan Wessberg
2007-07-11 10:01:28 UTC
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 |
