On 12 Jul, 2007, at 14:56, Simon Ruderich wrote:
today I had a problem that "port sync" wasn't working anymore. The problem was that it used a rsync version which was removed by me.
I didn't knew that macports was using hardcoded paths and so had to search for the offending configuration data.
After some time I thought I found it in this file: ${prefix}/share/macports/Tcl/port1.0/port_autoconf.tcl
I changed the values but it wasn't working. So I looked further and found it here: /Library/Tcl/macports1.0/macports_autoconf.tcl
So I have two questions about it: 1. Why is macports using hardcoded paths for this sort of values. I tried just using "rsync" and it works.
It's not actually using a hard-coded path. Rather, the path is set when you ./configure (or when `port selfupdate` ./configures behind the scenes) according to the RSYNC environment variable (if it exists). This is done because, were you to use the rsync port to install a faulty binary into /opt/local/bin, you would otherwise lose the ability to sync with MacPorts and get a working binary back. Instead, ./configure finds a working rsync and makes sure it's always used for that installation of MacPorts. If you grab the tarball from the downloads directory, and ./configure with $RSYNC set to the new path, then it should generate those files correctly. I'm not sure how selfupdate plays into this, though, since `port` messes with environment variables a bit.
2. Why are there two (configuration) files similar data.
These are generated from the same configure variables, so it's just a matter of convenience. They aren't meant to be edited after ./configure.
I had some problems with macports hardcoded paths some time ago when I tried to install multiple port installations. I never really fixed this and have to rename my port installations to get it work.
Chris