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@cobblehill:sal>port info tor tor 0.1.1.26, security/tor (Variants: universal) http://tor.eff.org/
sal@cobblehill:sal>port installed tor The following ports are currently installed: tor @0.1.1.26_0 (active) sal@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. James