The package net-analyzer/lft-2.5 is a version bump from net-analyzer-2.31. Unfortunately, in portage, 2.5 is less than 2.31, so portage will never attempt to upgrade or install the "latest" version (2.5). Renaming the package to lft-2.50 makes it install; but the ebuild needs to be modified to reflect the correct filename (i.e. doesn't try to download lft-2.50.tar.gz, rather lft-2.5.tar.gz instead). Reproducible: Always Steps to Reproduce:
Created attachment 69313 [details, diff] Patch to lft-2.5 ebuild to allow ebuild name lft-2.50 to work This patch will make the renamed ebuild "lft-2.50.ebuild" download the correct source tarball.
No, it shouldn't. The version matches upstream. Complaints about stupid versioning scheme need to go upstream, sorry.
I disagree, as I think this highlights a weakness in the way portage determines version numbers. Mathematically speaking, the decimal number 2.5 (two and a half) is greater than the number 2.31 (slighty less than 2 and one-third); so a case can be made that the version number has increased. Also, I was taught in maths that the decimal numbers "2.5" and "2.50" were equivalent. Portage, however, doesn't agree; and in my mind this is a Portage "feature" which could be addressed. ReAssign this bug to Portage if you want as a feature request or bug or whatever; but like it or not, the problem is in the way portage does math.
(In reply to comment #3) > Mathematically speaking, the decimal number 2.5 (two and a half) is greater than > the number 2.31 (slighty less than 2 and one-third); so a case can be made that > the version number has increased. Also, I was taught in maths that the decimal > numbers "2.5" and "2.50" were equivalent. Mathematically speaking, 5 < 31 and upstream versioning is b0rked. The above quoted conclusion is flawed, 2 is major version, 5 or 31 is minor version, those two are rightly considered completely separate of each other.
