selfupdate fails with old rsync_dir value in macports.conf

[gkshenaut]

Running sudo port -v selfupdate fails with the following error tail:

configure: === configuring in vendor/tcl/unix (/opt/local/var/macports/sources/rsync.macports.org/release/base/vendor/tcl/unix)
configure: error: no configure script found in vendor/tcl/unix
Command failed: cd /opt/local/var/macports/sources/rsync.macports.org/release/base && CC=/usr/bin/cc OBJC=/usr/bin/cc ./configure --prefix='/opt/local' --with-install-user='root' --with-install-group='wheel' --with-directory-mode='0755' --enable-readline && make SELFUPDATING=1 && make install SELFUPDATING=1
Exit code: 1
Error: Error installing new MacPorts base: command execution failed
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: /opt/local/bin/port: port selfupdate failed: Error installing new MacPorts base: command execution failed

I'm currently running macport v. 2.3.5, macos 10.12.3, XCode 8.2.1

[neverpanic (Clemens Lang)]

Thanks for the report. See also ​https://lists.macports.org/pipermail/macports-dev/2017-January/035306.html.

This happens because we fail to correctly sync symlinks from our folder-based rsync source. This rsync source is, however, not the default since a few versions and does not offer signed downloads of the MacPorts source code. You should compare your /opt/local/etc/macports/macports.conf to /opt/local/etc/macports/macports.conf.default and ensure that rsync_dir ends with release/tarballs/base.tar instead of release/base, which should solve this issue.

Since you seem to be using the default mirror, you should be able to comment the rsync_server and rsync_dir directives which will cause MacPorts to fall back to the default, which is release/tarballs/base.tar.

[neverpanic (Clemens Lang)]

See also ​https://lists.macports.org/pipermail/macports-dev/2017-January/035313.html.

[gkshenaut]

I commented out the two lines you suggested and selfupdate succeeded. Thanks.

I don't know why my macports.conf differs from the default. Perhaps long ago I was trying to work around something? Question: is there a potential downside to me copying macports.conf.default on top of macports.conf, if I want to have a completely vanilla macports?

Thanks in advance.

[neverpanic (Clemens Lang)]

If you haven't modified the defaults much copying the template file back over the config should be safe. Keep a backup, just in case, though. Our migration instructions recommend comparing directive by directive, and that's probably the safest approach.

[gkshenaut]

Thanks!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #53485.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #53527.

[neverpanic (Clemens Lang)]

See [ff4f0431784625f8b1256a18e70b0d4815cb4f20/macports-base], which fixes this for new installations (but since we never update the configuration automatically, this won't fix existing problems).

Also, I really recommend switching to the tarball approach outlined above.

[Mihai Moldovan <ionic@…>]

In b5daf1af/macports-base:

misc: add -l parameter to rsync calls.

Akin to updating the default macports.conf configuration file in
ff4f0431784625f8b1256a18e70b0d4815cb4f20 also change the actual defaults
everywhere.

Fixes: #53414

[Ionic (Mihai Moldovan)]

This should also fix existing and new installations, provided users didn't uncomment the option in their config file.

Yes, the tarball method is much preferred and users should switch to it. New installations already use that by default. This is just to unbreak older ones. I came across this problem a few month ago and fixed it ad-hoc on my machine, but was too lazy to follow-up in code. Here it is now.

[mf2k (Frank Schima)]

Has duplicate #53570.

[jmroot (Joshua Root)]

In bebd94ad/macports-base:

Warn when using unsigned rsync for base or ports

See: #53414

[jmroot (Joshua Root)]

Do we want to officially deprecate non-tarball rsync in 2.4.1 by including the above commit?

[neverpanic (Clemens Lang)]

Yes, please.

[Ionic (Mihai Moldovan)]

I think so, most people probably are just unaware that something changed - and some will pop up on IRC or the mailing lists and ask for instructions on how to get rid of the warning. But it's better to alert them of a better alternative.