No destroot after fetching archive

[Ryan Schmidt]

On Oct 25, 2011, at 00:44, Mike Alexander wrote:

> I just updated my MacPorts installation to SVN r86383 and tried to upgrade my ports.  The upgrade for audiofile failed with
> 
> --->  Computing dependencies for audiofile
> --->  Fetching archive for audiofile
> --->  Attempting to fetch audiofile-0.2.7_0+universal.darwin_10.i386-x86_64.tbz2 from http://packages.macports.org/audiofile
> --->  Attempting to fetch audiofile-0.2.7_0+universal.darwin_10.i386-x86_64.tbz2.rmd160 from http://packages.macports.org/audiofile
> --->  Installing audiofile @0.2.7_0+universal
> --->  Uninstalling audiofile @0.2.7_0+universal
> --->  Computing dependencies for audiofile
> --->  Installing audiofile @0.2.7_0+universal
> Error: Target org.macports.install returned: no destroot found at: /opt/local/var/macports/build/_Users_mta_macports_macports-trunk_dports_audio_audiofile/audiofile/work/destroot
> Log for audiofile is at: /opt/local/var/macports/logs/_Users_mta_macports_macports-trunk_dports_audio_audiofile/audiofile/main.log
> 
> It's right, there isn't any destroot for audiofile.  When I took a brief look at the TCL code it wasn't clear to me where the destroot was supposed to be created after fetching an archive.

The destroot is not created when an archive is used. MacPorts should not be looking for a destroot when using an archive. I don't see any references in portfile to the destroot, outside of the destroot phase, so I suspect a MacPorts base bug. I see that it is "Installing audiofile @0.2.7_0+universal" twice and I don't understand why. I've seen odd behavior along those lines myself, that I was never able to explain, nor to reproduce reliably, which is why I didn't file an issue.

> Does anyone know what I did wrong?

Probably nothing.

> When I tried the upgrade again with the "-s" option it worked fine.

Perhaps just cleaning and trying again would work too. If you haven't yet done so, it might be interesting to see that main.log file.