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.

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

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.

In addition, its common practice that nsplugin API plugin packages don't install the plugin binary directly beneath 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 plugin host applications without the need to duplicate the plugin binaries. The links are typically created during package 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

Design

nspluginwrapper basically allows to create a wrapper plugin that bridges amd64 and i386 worlds.

Extend Dependencies

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.

Install Places

Packages provide their native i386 plugin library in $pkglibdir on all architectures, e.g.

/usr/lib/i386-only-plugin/libi386-only-plugin.so

However, instead of creating links from the mozilla plugin host applications directly to this library directly, plugin packages should hook in a $pkgvardir reference to the to plugin host application:

# link $pkgvardir to various mozilla plugin host applications
/var/lib/i386-only-plugin/libi386-only-plugin.so /usr/lib/firefox/plugins/libi386-only-plugin.so
/var/lib/i386-only-plugin/libi386-only-plugin.so /usr/lib/iceape/plugins/libi386-only-plugin.so
/var/lib/i386-only-plugin/libi386-only-plugin.so /usr/lib/iceweasel/plugins/libi386-only-plugin.so
/var/lib/i386-only-plugin/libi386-only-plugin.so /usr/lib/mozilla/plugins/libi386-only-plugin.so

Install during Postinst

On i386 hosts plugins should ship a link for their plugin library in $pkgvardir, e.g. during postinst

# test for nspluginwrapper executable ... if it doesn't exist we are on architecture that
# doesn't want wrapper library; => install link to original lib:
if test ! -x /usr/bin/nspluginwrapper; then
   ln -s /usr/lib/i386-only-plugin/libi386-only-plugin.so /var/lib/i386-only-plugin/libi386-only-plugin.so
fi

In contrast, on amd64 hosts plugins must create a nspluginwrapper library during postinst; this library should go to $pkgvardir, e.g.

# test for nspluginwrapper executable ... if it does exist we are on architecture that
# wants a wrapper library; => install wrapper library:
if test -x /usr/bin/nspluginwrapper; then
   # test for nspluginwrapper ... if it exists we are on architecture that wants wrapper library
   # 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
fi

This will create an amd64 plugin library that can be used by amd64 builds of mozilla plugin hosts (e.g. firefox).

Install during Postinst (update-alternatives variant)

Example how to adapt the postinst script snippet from above to install an alternative:

# test for nspluginwrapper executable ... if it doesn't exist we are on architecture that
# doesn't want wrapper library; => install link to original lib:
if test ! -x /usr/bin/nspluginwrapper; then
   update-alternatives --install /usr/lib/xxx-plugin-common/xxx-plugin-alternative.so \
              xxx-plugin /usr/lib/i386-only-plugin/libi386-only-plugin.so 70
fi

In contrast, on amd64 hosts plugins must create a nspluginwrapper library during postinst; this library should go to $pkgvardir, e.g.

# test for nspluginwrapper executable ... if it does exist we are on architecture that
# wants a wrapper library; => install wrapper library:
if test -x /usr/bin/nspluginwrapper; then
   # test for nspluginwrapper ... if it exists we are on architecture that wants wrapper library
   # 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
   update-alternatives --install /usr/lib/xxx-plugin-common/xxx-plugin-alternative.so \
              xxx-plugin /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so 70

   /var/lib/i386-only-plugin/npwrapper.libi386-only-plugin.so
fi

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:

)

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. )


CategorySpec

FirefoxNspluginwrapperSpec (last edited 2008-08-06 16:15:19 by localhost)