new installation trouble

Ryan Schmidt ryandesign at
Tue Apr 24 22:00:22 UTC 2018

On Apr 22, 2018, at 23:59, Ulrich Wienands wrote:

> On Apr 22, 2018, at 10:18 PM, Ulrich Wienands wrote:
>> uli% sudo port -d selfupdate
>> Password:
>> DEBUG: Copying /Users/uli/Library/Preferences/ to /opt/local/var/macports/home/Library/Preferences
>> DEBUG: MacPorts sources location: /opt/local/var/macports/sources/
>> --->  Updating MacPorts base sources using rsync
>> DEBUG: system: /usr/bin/rsync -rtzvl --delete-after rsync:// /opt/local/var/macports/sources/
>> rsync: failed to connect to No route to host (65)
>> rsync error: error in socket IO (code 10) at /SourceCache/rsync/rsync-45/rsync/clientserver.c(105) [receiver=2.6.9]
>> Command failed: /usr/bin/rsync -rtzvl --delete-after rsync:// /opt/local/var/macports/sources/
>> Exit code: 10
>> [Ulis-MacBook-Pro:~] uli% 
>> So it says it cannot connect to But I can ping it & it responds well.

> Ok, solved it myself: It looks like a firewall prevents rsync from working. By Googling I found the workaround in editing the macports.conf file to use https: instead. Now watching installs.
> I do wonder whether there is a better way than to use Google to find the answer.

It is true that MacPorts in its default configuration requires an rsync server in order to sync the ports tree, and in all configurations requires rsync in order to selfupdate base. It is true that firewalls, especially overly restrictive corporate firewalls, can prevent access to rsync servers, or any other servers, but rsync is prone to being blocked in this way because it uses a less-familiar port number than web or email servers. It is an error for network administrators to configure firewalls to block access to rsync servers, but unfortunately we cannot fix all network administrators.

Switching sources.conf to use an http tarball for sync works around the problem, at the expense of needing to transfer the full set of portfiles every time you sync. rsync has the advantage of only needing to transfer the differences since the last time you synced, which uses less bandwidth and is faster.

Another option is to have sources.conf get the ports directly from the Git repository. Like rsync, git transfers only differences, so updates are quick, but the disk space required is greater, and your computer has to spend time updating the portindex, because the portindex is created by the rsync server and is not stored in the git repository.

It might be nice if MacPorts came preconfigured to know about these various ways of getting the ports, and if one fails, it could try the others automatically, but nobody has worked on adding such functionality yet.

MacPorts doesn't support any method other than rsync for selfupdate. If you can't access rsync servers, you can't selfupdate; you have to manually install new versions of MacPorts base when they're released, for example by downloading and running the new installer from our web site.

It might be nice if selfupdate could optionally get sources from a web server instead, but no work has been done on that yet. It might be nice if selfupdate could download a pre-compiled binary (the official installer, for example) instead of having to compile from source, but no work has been done on that either.

It is an old issue. See

More information about the macports-users mailing list