Bug 81022 - mozilla RPMs don't remove empty directories when removed
Summary: mozilla RPMs don't remove empty directories when removed
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mozilla
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Christopher Aillon
QA Contact:
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks: 79579 CambridgeTarget
TreeView+ depends on / blocked
 
Reported: 2003-01-03 15:55 UTC by Braden McDaniel
Modified: 2018-04-11 12:25 UTC (History)
6 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2007-02-05 12:53:18 UTC


Attachments (Terms of Use)
patch to add include dirs to package manifest (1.26 KB, text/plain)
2003-07-17 22:31 UTC, Jens Petersen
no flags Details

Description Braden McDaniel 2003-01-03 15:55:11 UTC
Description of problem:
When removed using "rpm -e", the mozilla RPMs don't remove directories that they
install (e.g., /usr/lib/mozilla-1.2.1, /usr/include/mozilla-1.2.1).

Version-Release number of selected component (if applicable):
1.2.1-3

Comment 1 Warren Togami 2003-02-03 07:33:08 UTC
Is this truly a bug?  Many other packages don't remove empty directories either.


Comment 2 Jens Petersen 2003-07-17 21:27:08 UTC
Yes, mozilla has lots of unowned directories:

% rpm -qf /usr/include/mozilla-1.4/mozilla-config.h
mozilla-devel-1.4-12
% rpm -qf /usr/include/mozilla-1.4
file /usr/include/mozilla-1.4 is not owned by any package
% rpm -qf /usr/include/mozilla-1.4/gtkembedmoz/gtkmozembed.h
mozilla-devel-1.4-12
% rpm -qf /usr/include/mozilla-1.4/gtkembedmoz
file /usr/include/mozilla-1.4/gtkembedmoz is not owned by any package

It would be nice to have all the directories in the manifest to prevent this:

% ls /usr/include/mozilla-1.[Tab]
 mozilla-1.3/   mozilla-1.4/   mozilla-1.4b/


Comment 3 Jens Petersen 2003-07-17 22:31:51 UTC
Created attachment 92991 [details]
patch to add include dirs to package manifest

Comment 4 Michael Lee Yohe 2003-08-12 15:02:07 UTC
This is, in general, a good idea.  I am wondering, however, if these directories
were left behind because some plugins tend to install themselves into
/usr/lib/mozilla-1.x instead of the symbolic link /usr/lib/mozilla.

I think some sort of logic would be good in the removal/upgrade process to
migrate all plugins from legacy directories to the current version directory. 
That way, people don't find themselves unable to view that particular applet or
flash object.

Comment 5 Braden McDaniel 2003-08-12 15:36:43 UTC
That would be bad. Plug-ins that are version-independent should be installing 
themselves in ${libdir}/mozilla/plugins, not the versioned directory.

Regardless, certainly a directory shouldn't be deleted by an RPM uninstall if 
it still has files in it.


Comment 6 Jens Petersen 2003-09-04 03:21:02 UTC
> Regardless, certainly a directory shouldn't be deleted by an RPM uninstall if 
> it still has files in it.

(And indeed rpm doesn't delete non-empty directories.)

Comment 8 Steve Snyder 2004-08-05 17:04:43 UTC
Just a reminder that, 1.5 years after being reported, this is still a
problem.  

After upgrading to mozilla-1.7.2 I noticed that directories
/usr/lib/mozilla-1.7 and /usr/include/mozilla-1.7 were still present
on my system.  As was the directory structures from the even older
mozilla-1.6 installation.  The RPM upgrade correctly removed the old
files in these directories, but left the directory structures in place.

These obsolete directory structures are useless and should be removed.

Comment 9 Jens Petersen 2004-08-09 03:19:05 UTC
This seems to be fixed in mozilla-1.7.2-0.2.0 finally. :)

Comment 10 Christopher Aillon 2005-03-31 10:52:14 UTC

*** This bug has been marked as a duplicate of 74160 ***

Comment 11 Braden McDaniel 2006-07-10 21:58:03 UTC
This problem persists. Upgrading from mozilla 1.7.12 to 1.7.13 leaves a bunch of
directories around.


Comment 12 Matěj Cepl 2007-02-05 12:53:18 UTC
Mozilla has been removed from Fedora, and this has been already fixed in firefox.


Note You need to log in before you can comment on or make changes to this bug.