Tor and unusual version numbers
jberry at macports.org
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
- 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