Bug 131247 - browsers should take ownership of /usr/lib/mozilla
Summary: browsers should take ownership of /usr/lib/mozilla
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: mozilla
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Christopher Aillon
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: FC4Blocker
TreeView+ depends on / blocked
 
Reported: 2004-08-30 14:28 UTC by Thomas Fitzsimmons
Modified: 2007-11-30 22:10 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-27 09:39:41 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Fix dir ownerships (521 bytes, patch)
2004-09-02 22:46 UTC, Ville Skyttä
no flags Details | Diff

Description Thomas Fitzsimmons 2004-08-30 14:28:03 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
Gecko/20040301

Description of problem:
For the Java plugin, and other plugin packages, we need a way to
express a dependency on "a web browser that uses plug-ins from 
/usr/lib/mozilla".  Ville Skytt� of jpackage.org suggests that all
browsers that use plugins from /usr/lib/mozilla should take ownership
of that directory.  Then plugin packages can depend on /usr/lib/mozilla.


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


How reproducible:
Always

Steps to Reproduce:
1. rpm -qf /usr/lib/mozilla


Actual Results:  /usr/lib/mozilla is not owned by any package.

Expected Results:  /usr/lib/mozilla should be owned by all browsers
that use plugins from that directory.

Additional info:

Comment 1 Ville Skyttä 2004-08-30 15:27:25 UTC
More precisely, I would suggest that these browser packages own both
the %{_libdir}/mozilla and %{_libdir}/mozilla/plugins directories, and
plugin packages would depend only on the actual plugin directory they
install stuff into, ie. %{_libdir}/mozilla/plugins.

For Fedora Core, I believe the affected browser packages would be
mozilla and kdebase (for konqueror).  epiphany already depends on
mozilla, so that could be left unchanged at least for now if you like.

For fedora.us, I will suggest this change to the firefox package if
this suggestion receives a warm welcome here :)

Comment 2 Ville Skyttä 2004-09-02 22:46:39 UTC
Created attachment 103410 [details]
Fix dir ownerships

In case of mozilla, the %{_libdir}/mozilla/plugins has been "owned" since a
long time ago, it seems.  However, there are a couple of unowned dirs in the
latest mozilla package, fix attached.

Comment 3 Ville Skyttä 2004-09-02 22:53:19 UTC
Bug 131667 has the patch implementing this for kdebase (konqueror).

Comment 4 Enrico Scholz 2004-09-03 13:57:41 UTC
An alternative solution:

Create a 'filesystem-mozilla' package owning these directories. Or
call it 'mozilla-plugin-base' or ...

Comment 5 Ville Skyttä 2004-09-03 17:40:33 UTC
As long as there's a solution that pulls in a compatible browser (so
that in this case, browser packages would depend on that new suggested
package), I don't care much about the implementation details.

My personal preference would be towards the simple directory ownership
approach in browsers though, because a package containing 2 empty
directories sounds a bit overkill to me.

In JPackage, we still need to base the dependency on a directory since
that's the closest to a cross-distribution approach there is AFAICT. 
(That does not "rule out" the separate package in comment 4 though as
long as the dependencies in browsers are in place.)

Comment 6 Thomas Fitzsimmons 2004-09-13 21:36:13 UTC
*** Bug 109791 has been marked as a duplicate of this bug. ***

Comment 8 Thomas Fitzsimmons 2005-01-04 21:57:43 UTC
I just made the plugin packages own the mozilla directory.  Is there a problem
with that approach?


Comment 9 Ville Skyttä 2005-01-04 22:10:51 UTC
Yes, there is a problem, see bug 131667 comment 3.  Please consider reverting
that change from the plugin package(s).

Comment 10 Thomas Fitzsimmons 2005-01-05 00:26:06 UTC
OK, I'll revert the change in the next release of the plugin package.  But why
do we need the ability to specify this dependency?  Why not just allow people to
install the plugin in /usr/lib/mozilla/plugins, even if there is no browser
installed that uses plugins from that directory?


Comment 11 Ville Skyttä 2005-01-05 06:12:24 UTC
The plugin is not useful without a browser that uses it... and it's trivial to
implement the proper dependency ("Requires: %{_libdir}/mozilla/plugins") once
browser packages own these directories.

AFAIK all relevant browser packages now do implement that, the only thing left
in this particular bug would be to apply the patch from comment 2, and to add
the above dependency to plugin package(s).

Comment 14 Thomas Fitzsimmons 2005-03-09 21:13:59 UTC
The next release of the RHEL3 and RHEL4 SDK packages will not own
%{_libdir}/mozilla/plugins.  Does the FC4 Firefox package take ownership of
%{_libdir}/mozilla/plugins yet?


Comment 15 Jay Turner 2005-03-10 07:19:44 UTC
firefox-1.0.1-5 does indeed own /usr/lib/mozilla/plugins.

Comment 16 Ville Skyttä 2005-03-10 14:27:19 UTC
According to the changelog firefox owns it since 0.99-1.0RC1.2.

Comment 17 Warren Togami 2005-03-29 08:32:44 UTC
This still an issue for FC4?
We should fix this eventually in RHEL4 too.

Comment 18 Thomas Fitzsimmons 2005-04-01 02:28:15 UTC
Both the FC4 and RHEL4 versions of Firefox and Konqueror own /usr/lib/mozilla
and /usr/lib/mozilla/plugins, so I think we can close this now.


Comment 19 Warren Togami 2005-04-01 05:07:33 UTC
OK, everything fixed then.  Closing RAWHIDE.

Comment 20 Ville Skyttä 2005-04-02 15:44:50 UTC
Please see comment 11 and comment 2, there are a few unowned dirs in the mozilla
package.  (Not directly related to the plugins dir issue, but they're already
reported here, so...)

Comment 21 Warren Togami 2005-04-27 09:39:41 UTC
Sorry please open a new bug with a tested patch against latest rawhide.  caillon
is already too busy and will ignore anything that doesn't apply that he would
need to dig through many comments to find.



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