[MacPorts] #15868: port-1.600: port sync fails with "please get a newer Subversion client"
Rainer Müller
raimue at macports.org
Mon Feb 16 23:20:28 PST 2009
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
More information about the macports-dev
mailing list