-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, 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. 2. Why are there two (configuration) files similar data. 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. Thanks for your help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGlnlAYRX4BO+zMikRCpMyAKCuZtn/5shIB4KC+8sh+q1HFTsNJACePM5x bSUwK8IzT+JggRQ+rIIM6IA= =1X0O -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Chris Pickel wrote:
On 12 Jul, 2007, at 14:56, Simon Ruderich wrote:
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.
I can see this problem. But maybe there could be added new variables for this task to "macports.conf". Then someone can change the used binaries later (to use an updated version for example). If someone messes with his rsync installation then he just has to remove this variable. Or macports should also use the $RSYNC variable on runtime.
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 still think there should be a configuration file for this. Then nobody has to mess with it. But the only solution at the moment is to reinstall macports and I don't think this should be necessary for such a simple task like renaming a binary.
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.
Does anybody has a solution for this? I still have to rename the directories to get it work.
Chris
Thanks for your reply, Simon PS: Sorry for the late reply. - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGm380YRX4BO+zMikRCoBaAJ9szo7mlC9DMDBtZd27rUJIpRqBgwCg1eCD KvQha89v0TDRtb3sripFx9U= =bP07 -----END PGP SIGNATURE-----
participants (2)
-
Chris Pickel
-
Simon Ruderich