Description of problem: Upgrading from firefox 1.5.0.8 to 1.5.0.9 leaves the directory "/usr/lib/firefox-1.5.0.8/updates/0" Version-Release number of selected component (if applicable): 1.5.0.9
Usually /usr/lib/firefox-VERSION/plugins/ is left orphaned if you install flash the plugin.
Fedora Core 6 is no longer supported, could you please reproduce this with the updated version of the currently supported distribution (Fedora 7, 8, or Rawhide)? If this issue turns out to still be reproducible, please let us know in this bug report. If after a month's time we have not heard back from you, we will have to close this bug as CANTFIX. Setting status to NEEDINFO, and awaiting information from the reporter. [This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or Gecko. If you see any other reason, why this bug shouldn't be closed, please, comment on it here.]
The upgrade from firefox 2.0.0.9 to 2.0.0.10 left the directory /usr/lib64/firefox-2.0.0.9. It is empty and (now, at least) unowned.
Could I get a output of ls -R /usr/lib*/firefox-* command (you can ommit /usr/lib64/firefox-2.0.0.10, or attach the file to this bug if it seems to big for you)?
I have already manually removed /usr/lib64/firefox-2.0.0.9. As I said, it was empty. Aside from that, we have: /usr/lib/firefox-2.0.0.8: plugins /usr/lib/firefox-2.0.0.8/plugins: nppdf.so /usr/lib/firefox-2.0.0.9: plugins /usr/lib/firefox-2.0.0.9/plugins: nppdf.so Sigh. It looks like nppdf.so comes from AdobeReader. And it is unowned; so not removed when that rpm is removed. It looks like the AdobeReader install process copies this file to every spot that looks like Gecko plugin directory. I don't know that this explains why /usr/lib64/firefox-2.0.0.9 was left around, though.
Yes, it does explain everything. rpm when upgrading/removing package will get through removing all files owned by the package and then removes all empty directories. Of course, when the directory is not empty it doesn't remove it (because apparently somebody else -- either other package, or administrator with some local customization -- wanted to have something there). This is IMHO The Right Thing(TM), and it will never ever change. Of course, there are ways around it (rm -rf in some package scripts), but to the best of my knowledge it won't be part of any firefox package. The conclusion is that you should complain with Adobe (BTW, evince is pretty good these days ;-)). There are ways how to make plugin packages behaving sanely and it seems that Adobe actually fixed flash-plugin to behave much better, so your complain with Adobe is not totally hopeless (I don't know if they have any kind of support for their RPM packages). For here, unfortunately, I have no other choice than close this as NOTABUG.
How does this explain why/usr/lib64/firefox-2.0.0.9 was left around? It was empty; so per what you say above, it should have been removed... right?
Yes, I have no idea. We will recheck it in the following packages.
Is it possible that the adobe reader plugin did something like wait to remove the plugin from the directory after firefox finished the uninstall of the older version? Not sure really. But if not, this is probably an rpm bug and not a firefox bug if empty directories are being left behind by rpm. I'm guessing something else is going on though...
The Adobe plug-in doesn't put anything under /usr/lib64.