Let's keep this discussion on the list. Be sure to use the Reply To All feature when you reply. On Apr 1, 2007, at 02:37, Bas den Hond wrote:

...

I'm familiar with the @version syntax for *uninstalling*, but I've never heard of it for installing. I can't see that usage described in the manpage either. Though if you see it there, please show me. To the best of my knowledge, MacPorts has no such capability.

...

So what gives? I guess I could remove the svn tree from sources.conf temporarily, but that seems klutzy...

Any explanation appreciated.

As I said, I only use my local svn working copy, and comment out the rsync source. You might try that as well. With the svn working copy you have the advantage that you can backdate any port to any version. Simply use "svn log" on the portfile to find the last revision number where the port was at the version you want, then use "svn up -r" to download that version of the portfile. Then "sudo port install foo" as usual, or if the port is already installed in a different version, "sudo port -nf upgrade foo" to force it to install again at the backdated version.

Thanks, that explains a lot.

I was assuming that Macports capabilities were orthogonal. That is, if the expression program@version means anything and can be used in an expression somewhere, it can be used everywhere... From a user's perspective, I think that should be the way it works.

It does not work that way, and it would be very difficult to implement that, given current MacPorts structure. As far as MacPorts knows, there is only one version of the portfile, which describes one particular version (and revision) of the software, and you can install that version and only that version. But you can specify variants too. So you can end up with all of "php5 @5.2.1+apache2", "php5 @5.2.1+fastcgi+mysql5" and "php5 @5.2.1+pear+sqlite" installed, to show but a few examples. When it comes time to uninstall, MacPorts needs to know exactly which one of those you would like to uninstall. That's why the uninstall action accepts a version/variant specifier. For situations where we want multiple versions of a software package to be available, multiple ports are created. See for example mysql, mysql4 and mysql5; apache, apache20 and apache2; php4 and php5; sqlite2 and sqlite3; glib1 and glib2; and gcc33, gcc34, gcc40, gcc41, gcc42 and gcc43, to name but a few examples -- and of course wxWidgets26 and wxWidgets which you already know about.

From that same perspective, I would urge the Macports developers to integrate the svn-trick into the port program itself. As things stand now, you think you're ready when you've read the port manpage, but eventually you discover you have to install and then learn svn, too, in order to manage any syncing problems.

You do not need to use or learn how to use Subversion in order to use MacPorts (not that it's difficult). The reason I am using a Subversion working copy for my ports tree is that I am a committer and need to have such a working copy in order to submit changes. If there is a problem in a portfile, we need to fix the problem in the portfile, not go back to an earlier version of the portfile. Of course, we're all volunteers here with other things to do besides maintain MacPorts, so sometimes it takes awhile to fix problems. If you know the solution, you can also just locally edit your portfile (with e.g. "port edit foo" or "cd `port dir foo` && open Portfile") to fix whatever the problem is. And you can create a ticket in the Trac system describing the problem and attach a patch so that someone with commit access can fix it for good. Creating such a patch is easier when you're using a Subversion working copy ("svn di > foo.diff"), but if you remember to make a copy of the portfile before your changes ("sudo cp Portfile Portfile.orig") then it's still easy enough to get the diff ("diff -u Portfile.orig Portfile > foo.diff"). Be aware that if you "sudo port sync" or "sudo port selfupdate" your local changes will be overwritten (if you're editing the portfiles in the tree that MacPorts syncs). The alternative is to set up a parallel local directory for your modified ports. I believe this strategy is described in some documentation somewhere, but I haven't followed it myself so I can't give you the specifics.