Hi, I'm running macports 1.4.3, which seems to be confused by programs with "unusual" versions. For example tor, on my system was version 0.1.1.26, and port outdated never noticed version 0.1.2.13 was available. Bye, Gufo
Hi, On 27/04/2007, at 06:26, Sbranzo wrote:
I'm running macports 1.4.3, which seems to be confused by programs with "unusual" versions. For example tor, on my system was version 0.1.1.26, and port outdated never noticed version 0.1.2.13 was available.
The only thing that comes to my mind is that port outdated won't pick up that there's a new version of a port available until PortIndex is updated, and that happens every twelve hours on the MacPorts rsync repository. In between such index updates, port sync will update the Portfiles to their latest state, but any port commands that run through PortIndex files (like port outdated) will be out of date. Darwin/MacPorts has behaved like this for a long time. If this isn't responsible for the behaviour you're seeing, I don't really have any other ideas, and it'd be great if you could post some more information about it. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms@macports.org
On 27/04/07 08:17, Boey Maun Suang wrote:
The only thing that comes to my mind is that port outdated won't pick up that there's a new version of a port available until PortIndex is updated, and that happens every twelve hours on the MacPorts rsync repository. In between such index updates, port sync will update the Portfiles to their latest state, but any port commands that run through PortIndex files (like port outdated) will be out of date.
I tought about it too, but in the last weeks IIRC I saw more that once tor showing up when port -v sync'ing. Today I just forced an upgrade, so I can't investigate more. Maybe someone who installed tor a while ago can verify this behaviour, without forcing the upgrade, in the next 12 hours or so. Gufo
On Apr 26, 2007, at 17:28, Sbranzo wrote:
On 27/04/07 08:17, Boey Maun Suang wrote:
The only thing that comes to my mind is that port outdated won't pick up that there's a new version of a port available until PortIndex is updated, and that happens every twelve hours on the MacPorts rsync repository. In between such index updates, port sync will update the Portfiles to their latest state, but any port commands that run through PortIndex files (like port outdated) will be out of date.
I tought about it too, but in the last weeks IIRC I saw more that once tor showing up when port -v sync'ing. Today I just forced an upgrade, so I can't investigate more. Maybe someone who installed tor a while ago can verify this behaviour, without forcing the upgrade, in the next 12 hours or so.
None of those changes updated tor's version number or necessitated a rebuild of tor, until today. You can check that by looking in the repository: http://trac.macosforge.org/projects/macports/log/trunk/dports/ security/tor 2006-12-30: r21078: tor 0.1.1.26 2007-01-03: r22478: now unmaintained 2007-04-05: r23615: now maintained by Boey Maun Suang; more hashes added 2007-04-14: r23998: maintainer email address updated 2007-04-16: r24088: livecheck feature added 2007-04-19: r24251: unnecessary environment variables removed 2007-04-26: r24491: tor 0.1.2.13
In general, when we've ahd thi happen in the past, we just bump the rev. I can, however, verify that 0.1.2.13 is not identified as newer than 0.1.1.26. If anyone would like me to run any tests, I'm leaving my system in the outdated state so we can play with it. -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University On Thu, 26 Apr 2007, Ryan Schmidt wrote: o o On Apr 26, 2007, at 17:28, Sbranzo wrote: o o > On 27/04/07 08:17, Boey Maun Suang wrote: o > o > > The only thing that comes to my mind is that port outdated won't pick o > > up that there's a new version of a port available until PortIndex is o > > updated, and that happens every twelve hours on the MacPorts rsync o > > repository. In between such index updates, port sync will update the o > > Portfiles to their latest state, but any port commands that run o > > through PortIndex files (like port outdated) will be out of date. o > o > I tought about it too, but in the last weeks IIRC I saw more that once o > tor showing up when port -v sync'ing. o > Today I just forced an upgrade, so I can't investigate more. Maybe o > someone who installed tor a while ago can verify this behaviour, without o > forcing the upgrade, in the next 12 hours or so. o o None of those changes updated tor's version number or necessitated a rebuild o of tor, until today. You can check that by looking in the repository: o
On Apr 26, 2007, at 6:56 PM, Salvatore Domenick Desiano wrote:
In general, when we've ahd thi happen in the past, we just bump the rev.
I can, however, verify that 0.1.2.13 is not identified as newer than 0.1.1.26. If anyone would like me to run any tests, I'm leaving my system in the outdated state so we can play with it.
-- Sal smile.
IIRC this already came up once but went unresolved. Four digit version numbers are not that common, so this is probably an overlook for that case either in the "get_outdated_ports" tcl proc in port(1) (base/src/port/port.tcl) or in the "rpm_vercomp" C function of the Pextlib library (base/src/pextlib1.0/vercomp.c), used said proc. I'd appreciate it if one of you could search trac for a similar report and put it in the "Needs developer review" milestone if not already there, or file it from scratch if one does not already exist. Thanks for the report and help! Regards,... -jmpp
On Apr 26, 2007, at 7:49 PM, Juan Manuel Palacios wrote:
IIRC this already came up once but went unresolved. Four digit version numbers are not that common, so this is probably an overlook for that case either in the "get_outdated_ports" tcl proc in port(1) (base/src/port/port.tcl) or in the "rpm_vercomp" C function of the Pextlib library (base/src/pextlib1.0/vercomp.c), used said proc. I'd appreciate it if one of you could search trac for a similar report and put it in the "Needs developer review" milestone if not already there, or file it from scratch if one does not already exist.
Thanks for the report and help! Regards,...
and for the immediate workaround, the port maintainer can bump the epoch. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 26 Apr, 2007, at 19:49, Juan Manuel Palacios wrote:
IIRC this already came up once but went unresolved. Four digit version numbers are not that common, so this is probably an overlook for that case either in the "get_outdated_ports" tcl proc in port(1) (base/src/port/port.tcl) or in the "rpm_vercomp" C function of the Pextlib library (base/src/pextlib1.0/vercomp.c), used said proc.
I looked over vercomp.c, and four-digit version numbers should not be treated differently. Vercomp simply compares each alphabetic or numeric segments in sequence. You should be able to verify this by running tclsh directly: % lappend auto_path /opt/local/share/darwinports/Tcl % package require Pextlib 1.0 % rpm-vercomp 0.1.1.26 0.1.2.13 get_outdated_ports and action_outdated make their comparisons with rpm-vercomp if epoch comparison is inconclusive. So, I'm not sure where this bug could be coming from. Chris
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? I figure that that must be the reason why I get The following installed ports are outdated: ... netpbm 10.26.30_0 > 10.26.39_0 ! ... when running "port -v outdated", since the changeset history for the netpbm Portfile shows an epoch line being inserted and then deleted. I suppose that leaving epoch in there permanently shouldn't hurt, but it's a bit misleading. 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. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms@macports.org
o > and for the immediate workaround, the port maintainer can bump the epoch. o o Isn't that going to muck things up for future versions if I then delete it o completely? I figure that that must be the reason why I get o netpbm 10.26.30_0 > 10.26.39_0 ! My understanding is that the epoch "outranks" the revision. So, until tor's version numbers start working with rpm-vercomp, we leave the epoch flag in. For packages that are always a problem, the epoch flag never leaves. It is, I guess, a "permanent" addition, since it is hard to go back until we can guarantee that everyone has gotten rid of their epoch-marked version. Though that raises a question: could epoch be interpreted as "if the current Portfile does not contain an epoch, ignore the epoch on the installed version"? Is that semantically correct? o A question now to everyone using tor or tor-devel: what does "port -v o outdated" yield for you? My testing, like that of Chris Pickel, suggests that o rpm-vercomp is working fine; I don't quite understand the Tcl to understand o exactly what port.tcl is doing. Yes, again, outdated does not pick up tor. -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University
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. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
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? James 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.
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. 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/ Tor provides a distributed network of servers (onion routers). Users bounce their TCP streams (web traffic, FTP, SSH, etc.) around the routers. This makes it hard for recipients, observers, and even the onion routers themselves to track the source of the stream. Library Dependencies: libevent, openssl, zlib Platforms: darwin Maintainers: nomaintainer@macports.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. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University On Fri, 27 Apr 2007, James Berry wrote: o So I thought I'd join this thread in order to perhaps help clarify and to seek o more information. So far, I haven't seen anything in the thread to lead me to o believe anything is actually wrong, though I don't seem to find the full text o of the original message. o o A few clarifications: o o - The only issues I know of with rpm_vercomp are that it doesn't necessarily o know how to deal with something like a change from an alpha to a numeric o component. Is 1.0.b2 greater than or less than 1.0.1, or greater or less than o 1.0, as an off-the-cuff example? Even upstream maintainers might not agree on o the answers. I believe rpm_vercomp works consistently in such cases, but it o can't outguess the system. o o - port outdated will show normally only show ports where the index has a o calculated larger version number than what is installed. If you pass the -v or o -d flag, then it will show any port where the versions don't match exactly, o with a "!" flag indicating this case. This can be useful when you suspect that o rpm_vercomp is failing to correctly intuit the version, as described above. o o o James o o o On Apr 27, 2007, at 5:32 AM, Daniel J. Luke wrote: o o > On Apr 27, 2007, at 2:59 PM, Boey Maun Suang wrote: o > > On 27/04/2007, at 11:20, Daniel J. Luke wrote: o > > o > > > and for the immediate workaround, the port maintainer can bump the o > > > epoch. o > > o > > Isn't that going to muck things up for future versions if I then delete it o > > completely? o > o > Yep, which is why you wouldn't delete it. o > o > > I suppose that leaving epoch in there permanently shouldn't hurt, but it's o > > a bit misleading. o > o > Well, epoch is there for situations where the version number doesn't give o > port enough information to determine correctly which version is later. (So o > for situations where the developer changes version number schemes, for o > example). o > o > > A question now to everyone using tor or tor-devel: what does "port -v o > > outdated" yield for you? My testing, like that of Chris Pickel, suggests o > > that rpm-vercomp is working fine; I don't quite understand the Tcl to o > > understand exactly what port.tcl is doing. o > o > If it's working fine, then you don't need it ... but if port isn't correctly o > determining the newer version is newer, you could use epoch to tell it that o > it is. o o _______________________________________________ o macports-dev mailing list o macports-dev@lists.macosforge.org o http://lists.macosforge.org/mailman/listinfo/macports-dev o
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
o So that looks perfectly normal. Installed is the same version that the port o index has listed, so it doesn't show up as outdated. Woah. Looks like I updated my tree, but not my PortIndex. Silly SVN (stupid user). I now withdraw all of my information and corroboration of concerns. -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University On Fri, 27 Apr 2007, James Berry wrote: o o On Apr 27, 2007, at 7:42 AM, Salvatore Domenick Desiano wrote: o o > o - yes, epoch is always considered first in outdated version comparisons. o > It is o > o undefined what would happen if an epoch was removed. Never do that. (I o > believe o > o that a port without an epoch is considered to have an epoch of zero). If o > o you've added epoch once to a port you should never remove it, only o > increase o > o it. That should not really be a problem. o > o > It seems interesting to me that adding an epoch, even once, condemns the o > Portfile to have epochs for eternity. Maybe this doesn't matter, but I o > thought it worth mentioning. It also may be worth including the epoch in o > the "outdated" display. o o Well, by the very definition of what epoch is, if you go back in time to a o previous epoch, then your numbering system gets messed up. o I'd be happy to include epoch in the outdated display. Perhaps only in -v o mode, and only if there is an epoch for a port? o o > o Now, can anybody give me any valid data on a case where there's a failure o > to o > o detect an outdated version? If so, what does port info show for version o > and o > o epoch, and what's the installed version? In other words, what is the data o > that o > o the outdated routines are comparing? o > o > I don't know if my version of port is too outdated to be useful, but I o > end up seeing: o > o > sal@cobblehill:sal>port info tor o > tor 0.1.1.26, security/tor (Variants: universal) o > http://tor.eff.org/ o o > sal@cobblehill:sal>port installed tor o > The following ports are currently installed: o > tor @0.1.1.26_0 (active) o > sal@cobblehill:sal>port -d outdated tor o > DEBUG: Found port in o > file:///Users/sal/Projects/MacPorts/macports-trunk/dports/security/tor o > No installed ports are outdated. o > o > -- Sal o > smile. o o o James o o
On 27 Apr, 2007, at 09:24, James Berry wrote:
- 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.
This is something that rpm-vercomp handles a bit weirdly, I believe: if it comes across a situation where one version has an alphabetic component but the other has a numeric, it always returns -1. In other words, 1.0.b2 < 1.0.1, but also 1.0.1 < 1.0.b2. So, whichever way the version number changed, port outdated should believe that the one in the Portfile is newer. Not exactly intuitive, but probably the most functional system. Chris
On Apr 27, 2007, at 10:53 AM, James Berry wrote:
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
Sal, did you sync your tree before performing this test....? I don't have tor installed, but I see: $[juan @MacBookPro: base](489/0,0) -> port search tor ---snip--- tor security/tor 0.1.2.13 anonymizing overlay network for TCP ---snip--- So I wouldn't be too sure about calling those results conclusive, I'm afraid. -jmpp
participants (8)
-
Boey Maun Suang
-
Chris Pickel
-
Daniel J. Luke
-
James Berry
-
Juan Manuel Palacios
-
Ryan Schmidt
-
Salvatore Domenick Desiano
-
Sbranzo