A Portfile interpreter created by mportopen will only end up actually
executing a subset of all targets, and may not execute any. Therefore,
splitting the code for running targets from that which is needed just
to parse the Portfile improves the speed of mportopen and reduces the
memory used by each open mport (which can really add up when installing
ports with large dependency graphs).
Initially only the portfetch code has been split, creating the new
portfetch_run package.
When attempting to update the local PortIndex from the precomputed
version for the current OS/arch, there is sometimes a preexisting
version with the correct mtime and size, but not the correct content.
With the default options, rsync fails to update it. This change
suppresses skipping based on size and time (for the index-related
files, not the tarball).
This bug has no obvious user-visible effect, since the bad PortIndex
fails the signature check and is then regenerated, costing extra
time but not malfunctioning. It's visible in the debug output.
TESTED:
Now correctly uses the downloaded index in a formerly failing case.
This currently triggers during the gtk3 build, suggesting there's a way
to close the file descriptors that isn't being caught by trace mode.
Work around this by re-establishing the connection when this happens.
Use the code that was being used to extract rsynced tarballs for the
tarball over http/ftp case as well. It looks like this also fixes the
bug that in the latter case, files no longer present in the tarball
were never deleted from the extracted location. (This appears to have
been the case since the daily tarball feature was added.)