Tor and unusual version numbers

James Berry jberry at
Fri Apr 27 07:53:18 PDT 2007

On Apr 27, 2007, at 7:42 AM, Salvatore Domenick Desiano wrote:

> o - yes, epoch is always considered first in outdated version  
> comparisons. It is
> o undefined what would happen if an epoch was removed. Never do  
> that. (I believe
> o that a port without an epoch is considered to have an epoch of  
> zero). If
> o you've added epoch once to a port you should never remove it,  
> only increase
> o it. That should not really be a problem.
> It seems interesting to me that adding an epoch, even once,  
> condemns the
> Portfile to have epochs for eternity. Maybe this doesn't matter, but I
> thought it worth mentioning. It also may be worth including the  
> epoch in
> the "outdated" display.

Well, by the very definition of what epoch is, if you go back in time  
to a previous epoch, then your numbering system gets messed up.
I'd be happy to include epoch in the outdated display. Perhaps only  
in -v mode, and only if there is an epoch for a port?

> o Now, can anybody give me any valid data on a case where there's a  
> failure to
> o detect an outdated version? If so, what does port info show for  
> version and
> o epoch, and what's the installed version? In other words, what is  
> the data that
> o the outdated routines are comparing?
> I don't know if my version of port is too outdated to be useful, but I
> end up seeing:
> sal at cobblehill:sal>port info tor
> tor, security/tor (Variants: universal)

> sal at cobblehill:sal>port installed tor
> The following ports are currently installed:
>   tor @ (active)
> sal at cobblehill:sal>port -d outdated tor
> DEBUG: Found port in
> file:///Users/sal/Projects/MacPorts/macports-trunk/dports/security/tor
> No installed ports are outdated.
> -- Sal
> smile.

So that looks perfectly normal. Installed is the same version that  
the port index has listed, so it doesn't show up as outdated.


More information about the macports-dev mailing list