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: | ports → base |
---|---|
Milestone: | → MacPorts base bugs |
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: | High → Normal |
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:5 Changed 16 years ago by tobypeterson
Milestone: | MacPorts base bugs → MacPorts Future |
---|
Milestone MacPorts base bugs deleted
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: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 Future → MacPorts 1.9.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Problem does not exist in registry2.0.
Regarding:
gnome-vfs probably depended on heimdal at the time that gnome-vfs was installed (but no longer does).