Opened 5 years ago
Last modified 5 years ago
#58751 reopened enhancement
MacPorts should bundle a newer rsync or allow overriding the default rsync
Reported by: | IRDonch (Roman Donchenko) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | |
Keywords: | Cc: | ||
Port: |
Description
I need to use a SOCKS proxy for rsync. It's normally possible through the RSYNC_CONNECT_PROG
variable; however, the version of rsync included with macOS is too old to support it. Moreover, Apple is very unlikely to update it due to their anti-GPLv3 policy. It would be nice if MacPorts included its own build of a newer version of rsync, so that features like this could be used.
Alternatively, MacPorts could at least support overriding the path to rsync. Then I could stick my own build into /usr/local
and use that.
Change History (11)
comment:1 Changed 5 years ago by kencu (Ken)
Summary: | MacPorts should bundle a newer rsync → MacPorts should bundle a newer rsync or allow overriding the default rsync |
---|---|
Type: | enhancement → request |
comment:2 Changed 5 years ago by kencu (Ken)
comment:3 Changed 5 years ago by mf2k (Frank Schima)
Type: | request → enhancement |
---|
@ kencu: A "Request" ticket type is only for requesting new ports. This was correctly set at "Enhancement".
comment:6 Changed 5 years ago by jmroot (Joshua Root)
As the names of those files imply, they are populated by the configure script, and you can specify a different rsync at configure time when you build from source.
comment:7 Changed 5 years ago by jmroot (Joshua Root)
Other workarounds could include running a proxy that can be used via RSYNC_PROXY and which connects to the SOCKS proxy, or syncing via alternate means: wiki:howto/PortTreeTarball wiki:howto/SyncingWithGit
comment:8 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → invalid |
---|---|
Status: | new → closed |
So, since MacPorts already supports specifying an alternate rsync program (using the --with-rsync
configure flag), there's nothing to do here.
comment:9 Changed 5 years ago by IRDonch (Roman Donchenko)
Resolution: | invalid |
---|---|
Status: | closed → reopened |
@ryandesign: That's not really sufficient. I don't want to build a custom version of MacPorts.
comment:10 Changed 5 years ago by kencu (Ken)
Roman, how would you like it to work?
The custom version of MacPorts just changes the rsync
location in those two lines I mentioned, using a configure option. You can edit those lines yourself, as above, instead.
I suppose there could be an environment variable that sets the rsync
to use -- MacPorts is pretty cautious about environment variables, though, and sanitizes most of them due to odd busted builds and other similar errors that are hard to debug...
Josh gave a few more ideas in comment 7 above...
Any other ideas come to mind for how you'd like to set the rsync
?
comment:11 Changed 5 years ago by IRDonch (Roman Donchenko)
An option in macports.conf
would be fine.
Although the best outcome would be for MacPorts to bundle the most recent rsync and use that, much like it already bundles Tcl.
It looks like the
rsync
used by MacPorts is specified in two places:and
You could try, for a test, installing a current
rsync
using MacPorts, and then edit those two lines to use it instead of the/usr/bin/rsync
that is specified in those lines.Those edits would last until the next MacPorts update, I think.
Of course, if you uninstalled or deactivated
rsync
, you'd have to change those lines back to the systemrsync
or things would not work properly.