Opened 17 years ago

Closed 15 years ago

#13054 closed defect (fixed)

incorrect dependents listed, require -f uninstall to fix

Reported by: william.allen.simpson@… Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts 1.9.0
Component: base Version: 1.5.2
Keywords: Cc: vinc17@…, gale@…, ryandesign (Ryan Carsten Schmidt), hahn.seb@…, michael.paesold@…
Port:

Description

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

Change History (13)

comment:1 Changed 17 years ago by ryandesign (Ryan Carsten Schmidt)

Component: portsbase
Milestone: MacPorts base bugs

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).

comment:2 Changed 17 years ago by 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.

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

Cc: william.allen.simpson@… removed
Priority: HighNormal

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.

comment:4 Changed 16 years ago by vinc17@…

Cc: vinc17@… added

Cc Me!

comment:5 Changed 16 years ago by tobypeterson

Milestone: MacPorts base bugsMacPorts Future

Milestone MacPorts base bugs deleted

comment:6 Changed 15 years ago by gale@…

Cc: gale@… added

Cc Me!

comment:7 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

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

comment:8 Changed 15 years ago by hahn.seb@…

Cc: hahn.seb@… added

Cc Me!

comment:9 Changed 15 years ago by michael.paesold@…

Cc: michael.paesold@… added

Cc Me!

comment:10 Changed 15 years ago by michael.paesold@…

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

comment:11 Changed 15 years ago by 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".

comment:12 Changed 15 years ago by 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

comment:13 Changed 15 years ago by jmroot (Joshua Root)

Milestone: MacPorts FutureMacPorts 1.9.0
Resolution: fixed
Status: newclosed

Problem does not exist in registry2.0.

Note: See TracTickets for help on using tickets.