<snip> 2.2 Version Specifications "No integer part of a version specification may contain more than eight digits." </snip> Why?
Because the version ordering rules make handling arbitrarily large parts a pain in the ass.
(In reply to comment #1) > Because the version ordering rules make handling arbitrarily large parts a pain > in the ass. Shrug; there's actually stuff in the tree using such versions, being a PITA to handle somewhere won't stop upstream from using such versions and will make it a PITA for maintainers to handle the versioning in ebuilds instead. sys-block/btrace: 0.0.20060428050322, 0.0.20060614042007 dev-lang/php: 5.2.4_pre200708051230-r2 (YYYYMMDDHHMM snapshots provided by upstream, don't see anything unreasonable about this).
(In reply to comment #1) > Because the version ordering rules make handling arbitrarily large parts a pain > in the ass. > Perhaps the limit should be bigger. Like 20.
Such restrictions are silly imo. What if upstream gives a package more than X numbers? The limit of less or equall 8 digits is a nonsense, which was specified by someone who didn't think about YYYYMMDDHHMM format, or at least didn't care about that. (In reply to comment #3) > Perhaps the limit should be bigger. Like 20. > I think limit of 20 digits is just a prevention. We all know, that upstream doesn't give such versions. So if, why do we use digits limit?
The restriction is eight because that's all you get with some Portage versions without bugs (note that not all bugs are easily visible, and some only become visible when you start doing strange things with leading zeroes). Anyone using more than that in the tree should be aware that some comparisons will give wrong results with some Portage versions.
(In reply to comment #5) > Anyone using more than that in the tree should be aware that some comparisons > will give wrong results with some Portage versions. Which ones? How usable those versions are with the current tree (bug 114798 e.g.)? Maybe portage folks could comment on this? I prefer forcing upgrade on users to hiding some rare bugs under artificial restrictions carpet, esp. when such restrictions affect what's already used in the tree. :)
(In reply to comment #5) > The restriction is eight because that's all you get with some Portage versions > without bugs (note that not all bugs are easily visible, and some only become > visible when you start doing strange things with leading zeroes). Anyone using > more than that in the tree should be aware that some comparisons will give > wrong results with some Portage versions. Don't overwhelm us with so many details.
If anyone really cares, they can work it out and dig through the code themselves. Otherwise, you can have the answer for free: eight is not known to have any unsafe results, more is.
(In reply to comment #6) > Which ones? How usable those versions are with the current tree (bug 114798 > e.g.)? Maybe portage folks could comment on this? I prefer forcing upgrade on > users to hiding some rare bugs under artificial restrictions carpet, esp. when > such restrictions affect what's already used in the tree. :) The limitations of obsolete versions of portage that practically nobody uses anymore should not define our specification (perhaps a note about obsolete behavior is warranted). Portage should be able to support an essentially arbitrary number of digits (limited by available memory) thanks to the way that python integer and long literals are implemented: http://docs.python.org/ref/integers.html
(In reply to comment #9) > Portage should be able to support an essentially arbitrary number of digits Please do some basic testing before making such claims in the future. This clearly isn't true with current stable: >>> portage.vercmp("1.0100000000000000001", "1.0100000000000000002") 0
(In reply to comment #10) > >>> portage.vercmp("1.0100000000000000001", "1.0100000000000000002") > 0 This is a special case that is only triggered when there is a period followed by a zero (we've discussed this in bug 170659). In that particular case, portage uses floating point numbers, for which the allowed range is implementation dependent: http://docs.python.org/ref/floating.html
Indeed, so as I said there is a limit, and eight characters is known to be safe, hence the wording in PMS.
(In reply to comment #11) > (In reply to comment #10) > > >>> portage.vercmp("1.0100000000000000001", "1.0100000000000000002") > > 0 > > This is a special case that is only triggered when there is a period followed > by a zero (we've discussed this in bug 170659). In that particular case, > portage uses floating point numbers, for which the allowed range is > implementation dependent: That particular issue is addressable; switch to str based comparison for the float component; logic is slightly fun for trailing zeros, but that's simple enough (make the smaller string the same length via appending zeros). There is one reason for the 8 char limit ciaran isn't specifying though; it fits within standard int- arguable whether that's a desired limitation, but worth having it all on the table.
that was the original logic actually when we decided to change the wording to only allow 8 numerics ... we catered to the idea that implementations may have decided to use uint32_t for the numeric at the time, no one was using values that large ... the php example is a bogus one; that number was generated by a Gentoo developer and could have just as easily been something smaller even if we bump it up to allow for 64bit, you're talking about a limit of 19, not 20, consecutive digits
(In reply to comment #14) > at the time, no one was using values that large ... the php example is a bogus > one; that number was generated by a Gentoo developer and could have just as > easily been something smaller Well not really, YYYYMMDDHHMM is what upstream is using for their snapshots, see http://snaps.php.net/.
(In reply to comment #15) > Well not really, YYYYMMDDHHMM is what upstream is using for their snapshots, > see > http://snaps.php.net/. They do that because they generate a snapshot more often than once a day and need each one to have a unique identifier. It's unlikely that more than one snapshot from the same day would get into the tree, so just the YYYYMMDD part may be used. Also, if you must, it's perfectly valid to separate the date and the time into two separate components, like YYYYMMDD.HHMM.
*** Bug 189508 has been marked as a duplicate of this bug. ***
As per http://www.gentoo.org/proj/en/council/meeting-logs/20080508.txt . This is now fixed. - ferdy
