In article <[EMAIL PROTECTED]> you wrote:
It's too bad upstream developers are so diverse in their attitudes about how
to number things... such that we have to deal with stuff like this. However,
that's a fact of life.
: 2) Use the Epoch system for the purpose it was intended, and move libc6
: from version ``0:2.0.7pre'' to ``1:2.0.7''.
I agree completely. If "the policy" says that using epochs to solve version
numbering problems caused by prerelease versions is wrong, then the policy is
in error, or at least misleading.
It would be completely appropriate for policy to suggest that using
pre-release numbering for the upstream version is wrong in a Debian package...
but once a package is numbered that way and out in the hands of users, the
epoch mechanism is the *least* ugly way of fixing the problem. We should
not be afraid to use it when we need it. I will certainly continue to do so
in packages that I adopt.
I personally think this ".99." stuff is really ugly. It is much better, I
think, to do something like
2.0.7 -> 2.0.7-n where ( n >= 1 )
2.0.8pre1 -> 2.0.8-0pre1
2.0.8 -> 2.0.8-n where ( n >= 1 )
So, in the present case, I'd bump the epoch to 1 this time, and then use
something like the above to avoid needing to bump it again if the upstream
version numbering continues to sort out of order.
But, I'm willing to admit that this is an issue of aesthetics, which means
we will never all agree on what to do... as long as *zero* manual package
handling is required to follow the proper sequencing of package versions, any
solution that works is acceptable to me.
Bdale
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
