Tor and unusual version numbers
jberry at macports.org
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 0.1.1.26, security/tor (Variants: universal)
> sal at cobblehill:sal>port installed tor
> The following ports are currently installed:
> tor @0.1.1.26_0 (active)
> sal at cobblehill:sal>port -d outdated tor
> DEBUG: Found port in
> No installed ports are outdated.
> -- Sal
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