MacPorts wrote:
#15868: port-1.600: port sync fails with "please get a newer Subversion client" ----------------------------------+----------------------------------------- Reporter: kimuraw@… | Owner: raimue@… Type: defect | Status: assigned Priority: Normal | Milestone: MacPorts 1.7.1 Component: base | Version: 1.6.0 Keywords: | Port: ----------------------------------+-----------------------------------------
Comment(by blb@…):
Then we need a list of those programs which must always be from the system and path those, since I think that would be the better direction than trying to list those which shouldn't be pathed. So bzip2, cvs, open, and rsync should be right? What about mtree and xar?
I am bringing this up on the mailing list, as this is the better place for discussions than Trac. In my opinion binaries which are vital for the operation of MacPorts should be used from an absolute path. As far as I see, this is only bzip2 in registry1.0 as you cannot activate/deactivate ports anymore when bzip2 is broken. 'port deactivate' can most probably fix easily all other issues introduced by broken binaries in PATH. In release_1_7 this is also 'rm' and 'ln' which were replaced on trunk in r45851 [1] (should we merge this?). For syncing I see no problem in using PATH for svn and rsync. Especially it solves the svn issue and users could benefit from rsync 3.x. Also note that there is no svn pre-installed on Tiger, so there has to be at least a fallback to PATH. For fetching there are no issues with svn, as we will always call the same version. git is not pre-installed, but it has a fallback to PATH which should be fine enough. For packaging and archiving currently all tools are used from PATH and I don't think we need to use autoconfed paths. Is there a port providing mtree at all? We should also think about tracemode. The current prefix is automatically in the sandbox, but I don't know if other paths from binpath are considered. Oh, and note that by PATH above I mean what port uses, namely the binpath from macports.conf. It is not the user environment. Rainer [1] https://trac.macports.org/changeset/45851