FirefoxNspluginwrapperSpec
Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Launchpad Entry: firefox-nspluginwrapper
Packages affected: nspluginwrapper ubuntu-desktop [amd64] flashplayer-nonfree
Summary
AMD64 is an important architecture for desktop linux; in consequence a good proportion of users lack the ability to use third party/proprietary plugins for firefox which usually are only available for i386 architecture only.
NsPluginwrapper tries to overcome this by interfacing the 64bit and 32bit world.
Release Note
Users of 64-bit firefox should be able to install 3rd-party (32-bit) plugins for firefox out of the box. In consequence we are now able to ship 3rdparty 32-bit firefox plugins as amd64 packages as well.
Rationale
The lack of proprietary firefox plugins on amd64 contributes negatively to the web-experience of amd64 ubuntu users.
Use Cases
- Play Flash content that cannot be properly processed by free flash alternatives
- Use Java Applets that don't work on free java plugins
Assumptions
This specification cannot assume that plugin libaries are available during build time. For example, the flashplayer-nonfree package doesn't ship the libflashplayer.so, but instead downloads it during install from the adobe website.
Design
nspluginwrapper basically allows to create a wrapper plugin that bridges amd64 and i386 worlds.
Status Quo
Currently plugins that implement the nsplugin API don't install the plugin binary directly in the firefox plugins directory, but put their library in $pkglibdir/ (e.g. /usr/lib/flashplugin-nonfree/).
In the past, this best practice evolved in order to make plugins available to multiple mozilla installs without the need to duplicate the plugin binaries in multiple places. The links however are usually created inside the package at build time (e.g. by using dh_link). Example taken from debian/links file for a imagined 'i386onlyplugin' package:
/usr/lib/i386-only-plugin/libi386-only-plugin.so /usr/lib/mozilla/plugins/libi386-only-plugin.so /usr/lib/i386-only-plugin/libi386-only-plugin.so /usr/lib/firefox/plugins/libi386-only-plugin.so /usr/lib/i386-only-plugin/libi386-only-plugin.so /usr/lib/iceape/plugins/libi386-only-plugin.so
This specification adapts this common practice ...
Base
i386 only nsplugin packages, can extend their set of supported architectures by adding a new Depends: for amd64:
Depends: nspluginwrapper (>= 0.9.91.4-2ubuntu1) [amd64], ... <<old depends>
Version 0.9.91.4-2ubuntu1 of nspluginwrapper ships a patch that allows the user to specify a directory, where to create the npwrapper library.
Standard Case
Packages provide their native i386 plugin library in $pkglibdir on all architectures, e.g.
/usr/lib/i386-only-plugin/libi386-only-plugin.so
On i386 hosts plugins should ship a link for their plugin library in $pkgvardir, e.g.
/usr/lib/i386-only-plugin/libi386-only-plugin.so /var/lib/i386-only-plugin/libi386-only-plugin.so
In contrast, on amd64 hosts plugins must create a nspluginwrapper library during postinst; this library should go to $pkgvardir, e.g.
# create nswrapper library in /var/lib/flashplugin-nonfree/ directory NSPLUGIN_DIR=/var/lib/i386-only-plugin/ nspluginwrapper -i /usr/lib/i386-only-plugin/libi386-only-plugin.so # rename nswrapper created library to a generic name which can be used to link this # library in a platform independent mannner mv /var/lib/i386-only-plugin/npwrapper.libi386-only-plugin.so /var/lib/i386-only-plugin/libi386-only-plugin.so
This will create an amd64 plugin library that can be used by amd64 builds of mozilla plugin hosts (e.g. firefox).
Plugins now create links for each mozilla plugin host target application to the $pkgvardir contained library:
/var/lib/i386-only-plugin/libi386-only-plugin.so /usr/lib/mozilla/plugins/libi386-only-plugin.so /var/lib/i386-only-plugin/libi386-only-plugin.so /usr/lib/firefox/plugins/libi386-only-plugin.so
Note, how /usr/lib/firefox/plugins/libi386-only-plugin.so is either the nspluginwrapper created library on amd64 or a link to the original native library on i386 hosts.
NEW - With Alternatives
In order to allow the use of nspluginwrapper, packages should still install their native 32-bit plugin library to $pkglibdir, e.g.
/usr/lib/i386-only-plugin/libi386-only-plugin.so
Implementation
( This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: )
UI Changes
( Should cover changes required to the UI, or specific UI that is required to implement this )
Code Changes
( Code changes should include an overview of what needs to change, and in some cases even the specific details. )
Migration
( Include:
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.
)
Test/Demo Plan
( It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.
This need not be added or completed until the specification is nearing beta. )
Outstanding Issues
( This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. )
BoF agenda and discussion
( Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. )