curl-ca-bundle @7.30.0_0 Install error: no destroot found

[daemonofchaos@…]

Terminal output from attempt to update:

/opt/local/bin/port selfupdate && /opt/local/bin/port upgrade outdated
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.1.3 installed,
MacPorts base version 2.1.3 downloaded.
--->  Updating the ports tree
--->  MacPorts base is already the latest version

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated
--->  Installing curl-ca-bundle @7.30.0_0
Error: org.macports.install for port curl-ca-bundle returned: no destroot found at: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_curl/curl-ca-bundle/work/destroot
Please see the log file for port curl-ca-bundle for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_curl/curl-ca-bundle/main.log
Error: Unable to upgrade port: 1

[daemonofchaos@…]

log file

[larryv (Lawrence Velázquez)]

Your log shows that the install was not clean. Run the following and attach the new main.log if it fails.

sudo port clean curl-ca-bundle && sudo port upgrade curl-ca-bundle

[daemonofchaos@…]

I had tried that prior to filing the ticket. I tried it again and this time the install completed without issue.

Can you point me to what in log file indicated the install wasn't clean so I know in the future?

Thank you for the help and I apologize for wasting your time.

[ryandesign (Ryan Carsten Schmidt)]

​http://guide.macports.org/chunked/project.html#project.tickets.prerequisites

This sounds like #29223.

[neverpanic (Clemens Lang)]

Replying to daemonofchaos@…:

Can you point me to what in log file indicated the install wasn't clean so I know in the future?

If the logfile contains "Skipping completed" the build attempt wasn't from scratch, or "clean" as we call it.

Thank you for the help and I apologize for wasting your time.

No problem. Maybe some time we'll actually find out why this happens at all and can fix it once and for all. While this sounds a lot like #29223, this bug has been confirmed fixed in 2.1.3. The only situation where this can still happen is if the build was started before the update to 2.1.3 (thus still using the old statefile format), since we can't remove support for the old statefiles from base at the moment and unconditionally re-start every build still using the old statefiles.

[daemonofchaos@…]

Somehow my first version of this got lost somehow. If it finally shows up then I apologize for the duplication.

As a final follow-up to this, the initial upgrade attempt was indeed interrupted due to my /usr/bin/tar being a symlink to /usr/bin/gnutar instead of the default BSD version of tar. Apparently the install process uses a flag in tar that isn't valid in gnutar, which caused the initial attempt to fail. I don't know if that helps resolve the underlying problem but hopefully that information helps.

In case you're wondering why I changed which tar I use it's because I work on a lot of Linux systems. When a tar file created by BSD tar is extracted on Linux a lot of unnecessary errors are displayed, e.g. ​http://superuser.com/questions/318809/linux-os-x-tar-incompatibility-tarballs-created-onos-x-give-errors-when-unt

Thanks for the info on what to look for in the log too! :)

[ryandesign (Ryan Carsten Schmidt)]

Replying to cal@…:

The only situation where this can still happen is if the build was started before the update to 2.1.3 (thus still using the old statefile format), since we can't remove support for the old statefiles from base at the moment and unconditionally re-start every build still using the old statefiles.

I've created #38862 to explore this idea.

[ryandesign (Ryan Carsten Schmidt)]

Replying to daemonofchaos@…:

the initial upgrade attempt was indeed interrupted due to my /usr/bin/tar being a symlink to /usr/bin/gnutar instead of the default BSD version of tar.

Right, it's definitely a user error to do that, and I'm glad you've un-done it now. On OS X, /usr/bin/tar must be BSD tar; various programs, including MacPorts, assume that. (Or rather: MacPorts' configure script detects that, but if you install a binary of MacPorts i.e. using the installer we post to our web site, then the configuration we ran on our build machines won't necessarily match the configuration of your machine; you could build MacPorts from source (e.g. force a selfupdate: sudo port -f selfupdate) if you want it to detect changes in your configuration.)

If you really want tar to be GNU tar in your terminal, the MacPorts-approved way to accomplish that, in a way that should not affect OS X itself or other programs that aren't being started using your terminal, is to install the gnutar port and add /opt/local/libexec/gnubin to your $PATH. Note that some other GNU utilities in MacPorts will also install unprefixed binaries into that location, so you might get other GNU utilities replacing OS X's BSD versions of those utilities, and this might cause various problems. You do so at your own risk.

[neverpanic (Clemens Lang)]

A different solution to the tar issue would be to add alias tar='gnutar' to your .bashrc (as explained in the stack overflow post). This will not affect other unrelated programs (like the $PATH change does), but doesn't work for scripts and binaries using tar or /usr/bin/tar (but those should check anyway whether they're dealing with GNU or BSD tar).

[daemonofchaos@…]

I had tried the alias first but then all of my scripts failed (as you mentioned). That is when I created the symlink. I will give the gnutar and coreutils a try and see how that works. If I encounter any difficulties later on I'll know to check if any of the commands that are failing are GNU or BSD.

Thank you both for the suggestions, information, and help. :)