Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#17992 closed defect (fixed)

non-installed ports cause warning about non-matching variants on upgrade

Reported by: jmroot (Joshua Root) Owned by: gwhitney
Priority: Normal Milestone: MacPorts 1.8.0
Component: base Version: 1.8.0
Keywords: Cc: gwhitney
Port:

Description

Example:

Warning: Skipping upgrade since XFree86 4.7.0_0 >= XFree86 4.7.0_0, even though installed variant  does not match +macosx. Specify -f to force upgrade.

The warning was introduced in r44362.

Change History (5)

comment:1 Changed 16 years ago by gwhitney

Owner: changed from macports-tickets@… to gwhitney@…
Status: newassigned

Obviously as the author of r44362 I'd like to look into this. But the above is not quite enough information for me to understand what's going on. What is the exact port upgrade command that produced this warning? What ports need to be installed (or not installed) for the erroneous warning to occur? The code that produces this warning thinks that XFree86 is installed; however, there is a hack (earlier in the code path, a hack I did not put in) which sets a port "installed outside MacPorts" (whatever that means) to appear to be installed. So I suspect we're hitting an interaction between that hack and the code I put in. (I have to say that I do not understand why the hack is necessary.) Could I have the output of the port upgrade lowest down the dependency chain which exhibits this behavior, but with -d specified? And the output of "port installed"? To reproduce, it would be nice to know what's the minimum set of packages I have to install to create this spurious warning on an upgrade, but you might not know that. If you do, so I could reproduce the issue here, that would be ideal. If not, I can try to debug it from the "-d" output.

Finally, as a MacPorts developer, you don't happen to have any idea what the purpose is of the hack in which an uninstalled port is marked as installed during the operation of "port upgrade", do you?

Thanks, sorry for the disruption r44362 is causing -- hopefully on balance it's still more good than harm.

comment:2 Changed 16 years ago by jmroot (Joshua Root)

Upgrading anything with a soft dependency on XFree86 is sufficient to reproduce (with XFree86 not installed). E.g. sudo port upgrade graphviz. Nothing needs to be outdated.

I think the hack is there because it blindly compares version_installed to version_in_tree, without first checking if the port is in fact installed (and hence if version_installed exists). So the former is set to the latter earlier on.

It would of course be far better to avoid such hacks altogether. The whole upgrade proc really needs a good cleanup and refactor.

Your change was good, but now we just need to file off the rough edges.

comment:3 Changed 16 years ago by jmroot (Joshua Root)

I think that since r37433 we should actually be able to do this:

--- src/macports1.0/macports.tcl        (revision 45299)
+++ src/macports1.0/macports.tcl        (working copy)
@@ -2017,6 +2017,7 @@
                 set depflag 1
                 # mark this depspec as satisfied in the cache
                 set depscache($dspec) 1
+                return
             }
 
         } else {

and then remove all checks/hacks later on that handle the possibility of the port not being installed.

comment:4 Changed 16 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: assignedclosed

Fixed in r45365. Now we just need to take care of the crazy activate/deactivate behaviour...

comment:5 Changed 16 years ago by jmroot (Joshua Root)

Milestone: MacPorts FutureMacPorts 1.8.0
Note: See TracTickets for help on using tickets.