duplicate entries in dependency list

[agentmonkey@…]

After going through a few upgrades via "port -a upgrade" I noticed that the upgrades only deactivated older versions of packages. After uninstalling the inactive ports manually (I needed to use -f since inactive ports can still have dependents) I noticed that their entries in the "dependency list" are not removed. For example:

~ $ sudo port installed | grep apr
  apr @1.2.6_0 (active)
  apr-util @1.2.6_0 (active)
-= rom@leviathan =- Sun May 07, 02:00 AM 
~ $

then,

-= rom@leviathan =- Sun May 07, 02:00 AM 
~ $ sudo port uninstall apr
Password:
--->  Unable to uninstall apr 1.2.6_0, the following ports depend on it:
--->    apr-util
--->    apr-util
--->    apr-util
--->    subversion
--->    subversion-javahlbindings
Error: /opt/local/bin/port: port uninstall failed: Please uninstall the ports that depend on apr first.
-= rom@leviathan =- Sun May 07, 02:16 AM 
~ $ 

Notice that apr-util appears three times but in the former command only one apr-util package is shown to be installed (apr-util @1.2.6_0). These "residual" packages are from previous inactive versions (because of upgrades) that were manually uninstalled.

[jmpp@…]

I'm not entirely sure the repeated entries in that dependents list is due to leftovers in the dependency list (dep_map), could very well be in the port(1) code that builds the list and echo's it to the user. But I'm sure developer review instead of wild guesses would best serve toward fixing this issue, therefore setting this ticket to that milestone ;-)

-jmpp

[eridius@…]

The duplicates are definitely in the dep_map. I just checked my own dep_map file on disk and it has duplicates right in there. I can't vouch for the source of the duplicates, but upgrade seems to be a reasonable assumption.

[eridius@…]

Ah hah, I've reproduced this issue.

1. Install port1 and port2, where port2 depends on port1 2. Upgrade your dports tree such that a new version of port2 is available 3. Deactivate port2 and install the new version. The default port upgrade behaviour does exactly this.

Now the dep_map contains two entries for port2 depending on port1. At this point, uninstalling port2 does not change the dep map, leaving behind two entries.

Uninstalling all copies of port2 will clean up the dep map, but as long as you have one version of port2 installed at all times, the duplicates will occur.

[eridius@…]

D'oh, wiki formatting lied to me. I needed a space before the list items.

1. Install port1 and port2, where port2 depends on port1
2. Upgrade your dports tree such that a new version of port2 is available
3. Deactivate port2 and install the new version. The default port upgrade behaviour does exactly this.

[jmpp@…]

Milestone Needs developer review deleted

[nox@…]

Is this still relevant?

[jmr@…]

The bit of code that is causing this problem is  here. The issue is that at that point you don't know which of the multiple versions of the port actually needed a given dependency (since dependencies can change between versions), and hence you don't know whether you can remove the dep map entry.

It would be possible to just trim the supernumerary entries from the dep map, but that would still leave you with spurious entries in cases where dependencies have been dropped from the new port version.

Maybe upgrade should clear the dep map entries for the old version before installing the new version?

[jmr@…]

proposed fix

[jmr@…]

Let's just prevent duplicate dep map entries being inserted in the first place. Attached patch implements this. We can make a tool to trim existing duplicates as well if we decide it's too inconvenient for users to remove them by uninstall + reinstall.

Nominating for the upcoming release.

[raimue@…]

Things like this should become faster with registry2.0, so just fix it in this slow way for now.

[jmr@…]

Committed the patch to trunk in r36745. I'll see about adding a command to clean out existing duplicates.

[jmr@…]

add the 'regclean' target

[jmr@…]

Attached a new patch which adds a 'regclean' target. This will remove all duplicate entries from the dep_map. It appears to do the right thing for me without breaking anything, but back up your dep_map.bz2 just in case. ;-)

[raimue@…]

Hm, do we really need a new action for this? I mean, this is a one time issue only. We could as well release some extra script which cleans the registry and only needs to be run one time (announced in the release notes). Or we add this script to postflight/make install in the next release to do it automatically. With the next release this will not happen anymore, so I don't see a reason for a new action.

[jmr@…]

Sure, an action isn't necessary if we're going to run the code in postflight and selfupdate. But it's quite convenient for testing purposes. :-)

[jmr@…]

Committed the clean_dep_map registry procedure in r39116.

[jmr@…]

a simple script to run clean_dep_map

[jmr@…]

Added a working version of the cleanup script to postflight and make install in r40142. Now all that is needed is for the MacPorts port to be updated to include the script in the .dmg resources.

[raimue@…]

Marking fixed.