Tor and unusual version numbers

James Berry jberry at
Fri Apr 27 06:24:43 PDT 2007

So I thought I'd join this thread in order to perhaps help clarify  
and to seek more information. So far, I haven't seen anything in the  
thread to lead me to believe anything is actually wrong, though I  
don't seem to find the full text of the original message.

A few clarifications:

  - yes, epoch is always considered first in outdated version  
comparisons. It is undefined what would happen if an epoch was  
removed. Never do that. (I believe that a port without an epoch is  
considered to have an epoch of zero). If you've added epoch once to a  
port you should never remove it, only increase it. That should not  
really be a problem.

  - The only issues I know of with rpm_vercomp are that it doesn't  
necessarily know how to deal with something like a change from an  
alpha to a numeric component. Is 1.0.b2 greater than or less than  
1.0.1, or greater or less than 1.0, as an off-the-cuff example? Even  
upstream maintainers might not agree on the answers. I believe  
rpm_vercomp works consistently in such cases, but it can't outguess  
the system.

  - port outdated will show normally only show ports where the index  
has a calculated larger version number than what is installed. If you  
pass the -v or -d flag, then it will show any port where the versions  
don't match exactly, with a "!" flag indicating this case. This can  
be useful when you suspect that rpm_vercomp is failing to correctly  
intuit the version, as described above.

Now, can anybody give me any valid data on a case where there's a  
failure to detect an outdated version? If so, what does port info  
show for version and epoch, and what's the installed version? In  
other words, what is the data that the outdated routines are comparing?


On Apr 27, 2007, at 5:32 AM, Daniel J. Luke wrote:

> On Apr 27, 2007, at 2:59 PM, Boey Maun Suang wrote:
>> On 27/04/2007, at 11:20, Daniel J. Luke wrote:
>>> and for the immediate workaround, the port maintainer can bump  
>>> the epoch.
>> Isn't that going to muck things up for future versions if I then  
>> delete it completely?
> Yep, which is why you wouldn't delete it.
>> I suppose that leaving epoch in there permanently shouldn't hurt,  
>> but it's a bit misleading.
> Well, epoch is there for situations where the version number  
> doesn't give port enough information to determine correctly which  
> version is later. (So for situations where the developer changes  
> version number schemes, for example).
>> A question now to everyone using tor or tor-devel: what does "port  
>> -v outdated" yield for you?  My testing, like that of Chris  
>> Pickel, suggests that rpm-vercomp is working fine; I don't quite  
>> understand the Tcl to understand exactly what port.tcl is doing.
> If it's working fine, then you don't need it ... but if port isn't  
> correctly determining the newer version is newer, you could use  
> epoch to tell it that it is.

More information about the macports-dev mailing list