incorrect dependents listed, require -f uninstall to fix

[william.allen.simpson@…]

The problem (perhaps) can occur when an old dependency is gone (OTOH, perhaps the db is corrupt) -- either way, the data should be checked for validity.

port deps heimdal
heimdal has no dependencies

port dependents heimdal
gnome-vfs depends on heimdal

But lo, that's not accurate:

port deps gnome-vfs
gnome-vfs has library dependencies on:
        gnome-mime-data
        gconf
        howl
        neon
        dbus
        openssl
        libidl
        dbus-glib
        libxml2
        libiconv
        gettext

In this case, (presumably) gnome-vfs installed heimdal, but will no longer compile while hiemdal is installed (#12753, #12789).

The dependents should actively check whether they are still needed. It requires a forced removal:

sudo port -f uninstall heimdal
Password:
--->  Unable to uninstall heimdal 0.7.2_1, the following ports depend on it:
--->    gnome-vfs
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Uninstalling heimdal 0.7.2_1

[ryandesign (Ryan Carsten Schmidt)]

Regarding:

port dependents heimdal
gnome-vfs depends on heimdal

gnome-vfs probably depended on heimdal at the time that gnome-vfs was installed (but no longer does).

[william.allen.simpson@…]

The gnome-vfs/heimdal conflict was the impetus, but merely used as an example. There should be no problem with a later port removing a depends. Indeed, it's not a problem to leave it in the heimdal entry -- until it is used.

At the time of use -- whether merely for display (where it should be ignored and not listed) or for an action (such as uninstall) that modifies the db -- the program should check to ensure that the entry is still valid.

[jmroot (Joshua Root)]

The problem is that the registry doesn't keep track of which version+variants of a port caused it to depend on another. So when you uninstall an old version, you can't remove just its dependencies and leave the new version's, because you don't know where each dependency came from. So they all stay there until the last version of the port is uninstalled.

This is fixable without a new registry format only in the case where you have just one old version + the current version. When you uninstall the old version, you can remove all the dep_map entries that don't apply to the current version (which you can determine using the Portfile). When there's more than one old version, you're sunk because you don't have the old portfiles around to figure out which one caused each dependency.

[vinc17@…]

Cc Me!

[tobypeterson]

Milestone MacPorts base bugs deleted

[gale@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #21191 which points out the negative implications this problem has on the replaced_by feature.

[hahn.seb@…]

Cc Me!

[michael.paesold@…]

Cc Me!

[michael.paesold@…]

Note that the resolution of bugs like #21167 is also affected by this.

[gale@…]

I would like to point out that for normal users who use MacPorts just to get software and don't want to be port hackers, this is really a serious problem with the MacPorts user interface.

It comes up quite often, as evidenced by the accumulating dups and related issues. Every time it comes up, MacPorts is very visibly broken, and it's not clear at all how to proceed. New users are almost always stuck until they are in contact with a MacPorts developer or other experienced user. Even after solving the problem several times, there is always a nagging doubt that this time, forcibly removing that port will somehow irreparable damage the system.

In my opinion, the priority of this issue should be higher than "Normal". And certainly, the milestone should be sooner than "MacPorts Future".

[hahn.seb@…]

I agree. I was totally stuck, and even asking several people on #macports didn't help until the information I needed to continue was added to #21167

[jmroot (Joshua Root)]

Problem does not exist in registry2.0.