ebuild app-office/mrproject-0.9.1 needs to depend on gnome-extra/libgsf
Not sure if it's rdepend, depend, or both.
checking 0.10 (which can be made stable anyway), libmrpoject needs libgsf and deps on it correctly. I see no direct reference to libgsf in the mrproject code. Do you have any solid proof for your claim (you really shouldve provided that in the first place).
spider, care to bump 0.10 to stable and get rid of all the older releases for all i care : force arches to follow.
Here's the error:
david@sidicpc22 david $ mrproject
mrproject: error while loading shared libraries: libgsf-1.so.1: cannot open shared object file: No such file or directory
david@sidicpc22 david $ su
root@sidicpc22 david # emerge -vp mrproject
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] app-office/mrproject-0.9.1
It should tell me I need libgsf should it not? It should see the libmrproject dep in mrproject, and then shouldn't portage look at libmrproject and notice that libmrproject is missing it's dependancy libgsf? Or shouldn't libgsf be an RDEPEND for mrproject as well?
Well, on second thought perhaps what I am dealing with is a lack of functionality in portage. I think I removed libgsf a long time ago, trying to make more hard drive space available and I removed packages which I thought I didn't need. What we need is apt-get like functionality when removing packages.
no it shouldnt, it should only list direct deps. In your case we would have an enormous dep list for eg. mrproject (think of X, fontconfig, glibc, a kernel, etc. etc.) . You removing stuff at random is not smart, it could break vital applications/libs.
The system is good as it is, the deep option probably wouldve caught the missing dep. Portage is not designed to fix user mistakes. It just checks if libmrproject is there and assumes all its deps are available as well, cause they should be.
Ok, I understand, not mrproject's fault, it's my fault for uninstalling libgsf. But I still think portage should have apt-get like behaviour, where if you try to uninstall libgsf, it tries to uninstall everything that depends on libgsf and everything else that depends on the thing that depends on libgsf, and so on, and so on. I'm going to go hunting in bugzilla for a RFE about this
Fixed and cleaned.