On May 10, 2007, at 2:36 AM, Paulo Moura wrote:

...

I'm in favor of getting the + out of your version number.

The "3.0.1+" version number is not something I control as is used by the third-party software. This software install on a directory named after this version number. Using a different version number in the portfile results in a broken installation. Moreover, what is important here is to fix the MacPorts parsing bug uncovered by my portfile, not finding a workaround for some specific portfile that only a few people care about.

Hi Paulo, When I rewrote major parts of the port(1) command driver a couple of years ago, I did put in accommodation for + in the version (the hack to terminate version with a /). Part of the problem is that the syntax has always allowed run together strings of version+-variants. I believe the problem in this case, however, is not in the port(1) command handler (as it can be forced to distinguish this case as I just said, but in other internal parts of macports that rely on using a combined version+variants string, and which don't automatically use the slash as I just described. As I recall these strings may even get used to build filenames. So yes, I believe that you _will_ run into problems with + in version numbers. I can't tell you exactly where/how/when, but it is a problem/ issue/restriction in the code. If somebody wants to work through this issue and patch the code, they are more than welcome to. Short of that, somebody should come up with a workaround for this particular port so that we can avoid the + in the version number: either by yelling at the port issuer, falling back to a version without the +, or (within macports) using a different version number (perhaps with an additional .1 component on the end instead of the +) to describe this version. The distfile key can then be used to explicitly name the file. Not idea, but I think it can be done. James