On 2007-05-10 15:55:53 -0700, James Berry wrote:
On May 10, 2007, at 7:44 AM, Vincent Lefevre wrote:
It seems that selfupdate got broken:
prunille:~> sudo port -d selfupdate DEBUG: Rebuilding the MacPorts base system if needed. Synchronizing from file:///Users/vinc17/wd/macosx/dports DEBUG: /opt/local/bin/svn update --non-interactive "/Users/vinc17/wd/macosx/dports"
It shouldn't update *my* SVN working copy. It was previously updating the standard path (?) with rsync. I suppose that it takes the paths from /opt/local/etc/ports/sources.conf, which contains here:
file:///Users/vinc17/wd/macosx/dports file:///Users/vinc17/software/dports rsync://rsync.macports.org/dpupdate/dports
But I use this for port installation only.
As Ryan points out, this was a change in 1.4.40. Clearly whoever made the change did not anticipate the problem you're having with it. We'd love to hear your suggestions for what the proper behavior should be in this case. What if the behavior was:
- Update the first sources.conf directory found that either (1) is an rsync url, or (2) is a valid svn repository.
I suppose you meant "is a valid working copy".
Would that rule fix things for you?
No, because the working copy is valid (the repository is also valid, but root cannot connect to it). First, the source.conf format should probably be changed so that one can tell which sources need to be updated by selfupdate and taken into account to upgrade MacPorts (the user may want to use some sources for the ports, and some other source for MacPorts itself). Second, if the directory doesn't belong to the user running the "port" command, then it should not be updated. Otherwise this is a real mess (in particular if one uses sudo). -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)