eix claims that WWW-Mechanize should be updated, when in fact it should not. Here is the output: [U] dev-perl/WWW-Mechanize Available versions: 1.16 (~)1.18 (~)1.20 (~)1.22 (~)1.24 1.30 1.0301 {test} Installed versions: 1.30(09:52:37 07/08/07)(-test) Homepage: http://search.cpan.org/~petdance/ Description: automate interaction with websites [U] dev-perl/WWW-Mechanize (1.30@07/08/07 -> 1.0301): automate interaction with websites Thanks! Reproducible: Always
To be explicit, it looks like eix is chomping the leading zero from the partial version "0301" and views it as an upgrade over "30".
(In reply to comment #1) > To be explicit, it looks like eix is chomping the leading zero from the > partial version "0301" and views it as an upgrade over "30". Yes. eix stores all numbers as numbers in its database. That's the only reasonable thing, since version numbers with leading zero's are not documented and, as I understood, are therefore deprecated. Leading zero's are really unclear. For instance, would 0301 be older or younger than 3? And how about 03010? Or 00301?
Perhaps because the full version is '1.0301' the "leading" zero is in fact significant to the overall version. If in fact Portage calls for ebuilds not to use version parts with leading zeroes, then perhaps we can get this very old ebuild removed please?
I am not sure whether this is the best solution. Currently, at least the following packages in the tree have versions relying on the strange leading-0 behavior as well and thus the corresponding versions would need to be cleaned up (or masked) for the same reason: dev-perl/Class-MakeMethods-1.009 (vs. 1.01) dev-perl/Convert-UUlib-1.051 (vs. 1.06) dev-perl/Term-ReadLine-Perl-1.0203 (vs. 1.03.02) dev-perl/cache-mmap-0.081 (vs. 0.09) Of course, I could easily change eix's database format and save the number of leading zeroes. However, it should be clarified anyway how these versions should be sorted. eix could just "imitate" portage's current behavior, but I am really not sure whether this is actually the desired behavior of portage.
a) treecleaners does not remove packages that have a maintainer. b) the removal of WWW-Mechanize has nothing to do with what this bug is about. if you want it removed, submit a new bug.
In eix's current svn trunk (eix-0.10.0) the number of leading zeroes is saved in the database. The following rules are used for comparison, although I have not tested whether this is what portage does: a) Any versionpart with a leading zero is smaller than any versionpart starting with 1-9 as leading digit (the versionpart "0" has by definition a leading zero). b) Two numbers with leading zeroes are compared "alphabetically". c) Two numbers with 1-9 as leading digits are compared numerically. Only the following packages (besides the earlier mentioned) have currently versions which rely on such a strange rule instead of numerical comparison: dev-perl/XML-RSS-Feed-2.04 (vs. 2.1) (but both versions are outdated by newer versions, anyway) games-puzzle/twindistress-1.03 (vs. 1.1.0) net-misc/iputils-021109-r3 (vs. 9999) (but both are outdated by newer versions; morover, 9999 has no keyword).
Since eix-0.10.0 is now in the tree, I close this bug. Feel free to reopen the bug or file a new one if you observe that the chosen comparison algorithm differs from portage's behavior.
