Red Hat Bugzilla – Bug 220936
Upgrading firefox leaves orphaned directories
Last modified: 2007-12-12 11:40:49 EST
Description of problem:
Upgrading from firefox 126.96.36.199 to 188.8.131.52 leaves the directory
Version-Release number of selected component (if applicable):
Usually /usr/lib/firefox-VERSION/plugins/ is left orphaned if you install flash
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 184.108.40.206 to 220.127.116.11 left the directory
/usr/lib64/firefox-18.104.22.168. 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-22.214.171.124, or attach the file to this
bug if it seems to big for you)?
I have already manually removed /usr/lib64/firefox-126.96.36.199. As I said, it was empty.
Aside from that, we have:
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-188.8.131.52 was left around,
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-184.108.40.206 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.