Bug 628804

Summary:	Please provide alternatives support in gnash-plugin
Product:	[Fedora] Fedora	Reporter:	Hicham HAOUARI <hicham.haouari>
Component:	gnash	Assignee:	Kevin Kofler <kevin>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	13	CC:	jreznik, kevin, pertusus
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-08-31 18:05:04 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Hicham HAOUARI 2010-08-31 05:25:30 UTC

Description of problem:
Currently gnash installs its mozilla plugin directly into %{_libdir}/mozilla/plugins/libgnashplugin.so, but that is not optimal if the user installs third party flash handlers, and causes users to report invalid bugs.

The obvious solution is to provide a flash alternative, so that only a flash plugin can be used in the browser at a time.

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

How reproducible:
Always

Steps to Reproduce:
1.Install gnash
2.Install a third party flash plugin
3.See weird behavior inside the browser
  
Actual results:
Weird behavior inside the browser due to conflicts between the plugins

Expected results:
Only one plugin should be used at a time

Comment 1 Hicham HAOUARI 2010-08-31 05:27:47 UTC

And please add a virtual provides in plugin package :

Provides: flash-plugin = %{version}-%{release}

Comment 2 Kevin Kofler 2010-08-31 18:05:04 UTC

Sorry, but as discussed on IRC:
* I really don't think alternatives makes sense to use here, as there's no file conflict to avoid. Having the browser pick a random plugin is no worse than alternatives doing so, and if you're going to set a (systemwide!) alternative, you can just yum remove the one you don't want. Plus, there are other ways to enforce priorities locally if really wanted (symlink into a higher-priority path, which can even be tuned per user).
* A big implementation roadblock is also that Adobe is extremely unlikely to ever support alternatives in its flash-plugin RPM.
* The Provides: flash-plugin is also unhelpful because the only people who'll ever explicitly ask for flash-plugin are those who want the Adobe one, and I don't see a package requiring a random Flash implementation either.