1.7 - install/upgrade broken with direct/archivemode

[danielluke (Daniel J. Luke)]

install and upgrade insist on unarchiving already installed dependencies when running upgrade (even with -n) or install.

Things still work (just very inefficiently) as long as the portfile hasn't been modified since the archive was created (as MacPorts will just unarchive and then notice that the port was already installed and continue), However, if there modification time for the Portfile is later than the archive, Macports will generate an error and stop the install or upgrade.

I first noticed this with only upgrade and didn't find the problem in the upgrade code, but then noticed it also happens with install.

If I have time, I'll track this down, but if someone has an idea of what might have changed to cause this, that would be helpful.

[blb@…]

Does this occur when only one install of the port being unnecessarily unarchived is available, or when there are multiple choices for the that port?

Also, what's the error output from port when the Portfile is later than the archive?

[danielluke (Daniel J. Luke)]

Replying to blb@…:

Does this occur when only one install of the port being unnecessarily unarchived is available, or when there are multiple choices for the that port?

I'm not sure what you're asking since with direct mode there's only ever one choice that's available (the current portfile's version/revision) as that's the only archive that will be looked for.

I see it happen with ports that I only have one archive (the current version/revision) and ports that have multiple archives available, though.

When looking at one of the ports where I see this problem, it's always the third time it appears that MacPorts is looking to see if it's installed that that lookup fails and MacPorts decides to unarchive it (in order to install it). If the Portfile hasn't changed, of course, the install is skipped after the unarchive since MacPorts notices that the port is already installed.

Also, what's the error output from port when the Portfile is later than the archive?

% sudo touch port dir db46 % sudo port -dv upgrade subversion-javahlbindings ... ---> Installing db46 @4.6.21_3 DEBUG: Executing org.macports.install (db46) Error: Target org.macports.install returned: Registry error: db46 @4.6.21_3 already registered as installed. Please uninstall it first. Warning: the following items did not execute (for db46): org.macports.install Error: The following dependencies failed to build: apr-util db46 cyrus-sasl2 zlib gettext junit hamcrest-core apache-ant

[danielluke (Daniel J. Luke)]

Replying to dluke@…:

sorry, forgot WikiFormatting

% sudo touch `port dir db46`
% sudo port -dv upgrade subversion-javahlbindings
...
--->  Installing db46 @4.6.21_3
DEBUG: Executing org.macports.install (db46)
Error: Target org.macports.install returned: Registry error: db46 @4.6.21_3 already registered as installed.  Please uninstall it first.
Warning: the following items did not execute (for db46): org.macports.install
Error: The following dependencies failed to build: apr-util db46 cyrus-sasl2 zlib gettext junit hamcrest-core apache-ant

[blb@…]

Replying to dluke@…:

I'm not sure what you're asking since with direct mode there's only ever one choice that's available (the current portfile's version/revision) as that's the only archive that will be looked for.

I see it happen with ports that I only have one archive (the current version/revision) and ports that have multiple archives available, though.

Sorry, 'twas a bit vague. Basically I was wondering if you see this only when a port has multiple archives available, where at least two are for the same version of the port but with different variants. For example, widget-1.0+foo and widget-1.0+bar. Basically I was trying to determine if there may be some overlap with #16085. But if it also happens with only the one archive available, then it probably isn't.

[jmroot (Joshua Root)]

Debug output for the 'working' case would be handy too.

[blb@…]

Should be fixed on trunk in r48230 and merge to 1.7 branch in r48231. Can you either verify from trunk, the 1.7 branch, or applying that change to your install?

[danielluke (Daniel J. Luke)]

I've just verified that it works from trunk.

Thanks!

[blb@…]

Thanks for the quick confirmation.