The title is just an example. There are some packages that use the yyyymmgg syntax for the version, and that number nowadays is always > than 9999. But -9999 versions usually indicate a svn build or anyways the bleeding-edge and nothing should be "higher" than them. That's a bit conceptual, but I hope you will find a workaround to this - seems reasonable to me.
agreed. It should be easy to fix this: if a version number can be parsed as a date (there are very few formats, all of which are easy to detect with a regexp), then it should be seen as less than 9999.
also, this shouldn't be a maintainer issue, as there are dozens of packages using date versioning...
A snapshot package for example could easily be called in that yyyymmdd format rather than yyyy.mm.dd or whatever, but that's a portage problem imo. -9999 is a convention, if one thought about this problem, probably -9999 would be -99999999 now. A practical example is outside the official portage tree, in the kdesvn-portage overlay. media-plugins/kipi-plugins has a 4.1 slot called that way (it's still a snapshot) and a svn slot called -9999
(In reply to comment #1) > agreed. It should be easy to fix this: if a version number can be parsed as a > date (there are very few formats, all of which are easy to detect with a > regexp), then it should be seen as less than 9999. > Or easier: if [-9999] then [latest]
This is not a bug, it's the expected and logic behavior. For the short term, just use something sensible like '-99999999' or '-9999999999999999'. For the long term, this could be addressed with GLEP 54 [1] [1] http://www.gentoo.org/proj/en/glep/glep-0054.html
(In reply to comment #4) > (In reply to comment #1) > > agreed. It should be easy to fix this: if a version number can be parsed as a > > date (there are very few formats, all of which are easy to detect with a > > regexp), then it should be seen as less than 9999. > > > > Or easier: if [-9999] then [latest] > So what you're saying is that 2 < 10 < 1000 < 9000 < 9900 < 9990 < 9998 < 10000 < ... < 9999? That makes sense... See, the solution is so much easier and it's called glep 54.
There is no reason to add special technical meaning to arbitrary numbers, even if there is an unofficial convention to use that number for a certain purpose.
