* Upstream * By default will not wrap native plugins unless -n or --native is passed. * Directories: - get_user_mozilla_plugin_dir is straight-forward: which is ~/.mozilla/plugins/ if it exists. - get_system_mozilla_plugin_dir: It checks a ton of directories that are distro specific and in some cases uses the LIB ($lib64, "lib" or "lib64") value. Pick the first that exists or LIBDIR/mozilla/plugins if none exist. - Plugins searched for in directories returned by get_mozilla_plugin_dirs. - List is a ton of hard-coded paths. Not conditioned on anything but some BSD and sun-specific paths. - Also add get_user_mozilla_plugin_dir. - Interestingly, there is nothing that ensures get_system_mozilla_plugin_dir is in this list. * Can list plugins with -l/--list - Lists everything in get_mozilla_plugin_dirs * Can wrap plugins with -i/--install - Either give it a list of plugins, or, if --auto, it will pick all plugins in get_mozilla_plugin_dirs which have a wrapper available for the architecture. - Wrapper plugins are not considered plugins. - When installing a plugin, - Unless the plugin that lives in ~root, try to install system-wide. Always install in get_system_mozilla_plugin_dir. - If we can install system-wide, stop. - I guess that check is very sketchy for "don't look in ~/.mozilla/plugins if you're root". - If plugin already has an up-to-date system-wide wrapper, skip it. Logic only checks get_system_mozilla_plugin_dir/NPW_WRAPPER_BASE.plugin_base. - This is incorrect in the face of Fedora's --prefix argument. - Otherwise, install into ~/.mozilla/plugins/. - An installed plugin is assumed to have file name NPWWRAPPER_BASE.plugin_name. - This breaks if you have two of the same plugin (with the same name) installed, unless you're Fedora and have the prefix thing. - Some logic to pick a mode (0755 for system, 0700 otherwise) * Can update plugins with -u/--update - Either give it a list of plugins, or, if --auto, look at all wrapper plugins in get_mozilla_plugin_dirs. This is actually not get_system_mozilla_plugin_dir which seems off. - When updating a wrapped plugin, - If there exists an up-to-date system-wide wrapper, and this isn't one, remove it. - If there exists a system-wide wrapper, up-to-date or not, and this one lives in ~root, remove the wrapper and re-install it into ~root/.mozilla/plugins. Ow. - If the plugin had been modified since the wrapper, re-install the wrapper. - If the wrapper's ident does not match ours, re-install it. * And you can remove plugins with -r/--remove, but it's pretty boring. Just unlink where you would expect. * Debian - On postinst, call nspluginwrapper -v -n -s -a -u, if nspluginwrapper/auto_update is set. - Patches to this logic. - Add command-line option -n/--nosymlink. Nevermind that -n already exists as --native, so it can't actually be used in short form. - Instead of using /usr/lib/mozilla/plugins as get_system_mozilla_plugin_dir, use LIBDIR/nspluginwrapper/plugins instead. - On plugin install, if on Debian, this is a system wrapper, and unless --nosymlink is passed, - Create a symlink in LIBDIR/mozilla/plugins/BASENAME to the plugin. - Print "failed" on error. I think this will cause problems if the symlink already exists, which is relatively harmless but will give a disturbing "failed" message. (Unless the symlink exists and points somewhere else, which may be bad.) - On plugin remove, if on Debian and unless --nosymlink is passed, - Take the base name of the plugin, go to LIBDIR/mozilla/plugins/BASENAME. If it is a symlink to where the plugin is now installed, delete it. - If NSPLUGIN_DIR is set, pretend that is the get_system_mozilla_plugin_dir unconditionally. - Is this used by anyone? Looks like it was imported from Ubuntu. - This is used by Ubuntu at least when installing Flash. I presume Debian too since they took it? - Add a command-line option -s/--systemonly. - If it is set, then change -u -a to iterate only over get_system_mozilla_plugin_dir. Honestly, this is probably not insane as default logic. * Fedora - Fedora does not actually call nspluginwrapper directly. They have a plugin-config tool, written in C, that eventually forks out to the nspluginwrapper binary. It also contains some code (taken from nspluginwrapper?) to detect plugins and whatnot. - There is a patch to npw-config.c - It rewrites the command-line parser to support flags with arguments and adds --prefix and --dir. - prefix replaces NPW_WRAPPER_BASE. Though it doesn't replace it in has_system_wide_wrapper_plugin, and it's unclear if there is a right answer there. The wrapper uses it to name the plugin something like npwrapper_32_32.something. - dir overrides the directory picking logic and always installs the plugin into that directory. If unset, we continue on with the logic from before. - It also sets LOADER to "" npw-viewer.sh if TARGET_ARCH is x86_64 in the ARCH != TARGET_ARCH case statement. It's not clear why this is done. If LOADER is empty, that check underneath will cause it to fail anyway, and the code doesn't distinguish between an empty and an unset LOADER. It also is probably wrong anyway? If you're trying to run x86_64 on something that's not x86_64, I imagine you're on, say, ppc. In which case, the loader should be a qemu-x86_64 or something. Maybe 64-bit plugin on 32-bit browser? - I haven't read the plugin-config tool, but I assume it exists to implement some completely different plugin installation logic. The -p and -d read very much like trying to have total control over where the wrapper goes. Presumably the reason it's in C is to be able to check if something is a plugin. In which case, arguably the right thing to do is to ship a npconfig or something tool. It will provide commands like is_plugin FILE, is_wrapper FILE, install_wrapper PLUGIN WRAPPER, and let distros who want to do random things make a shell script. For distros who don't want custom logic, reimplement the existing nspluginwrapper logic as a shell script and try to remain compatible for now. * Gentoo - No patches to this logic. * OpenSUSE - No patches to this logic. * Ubuntu - postinst - Looks in /usr/lib/nspluginwrapper/dirs.d/* and makes NSPLUGIN_DIRS out of it. - Then we run nspluginwrapper -a -v -u with it set. - If the version is before 1.2.2-0ubuntu5 then blow away /usr/lib/{mozilla,firefox,seamonke,iceweasel}/npwrapper.*.so. - Patches: - The symlink patch again - Like Debian, change the Debian plugin directory. - Add the same --nosymlink argument. - Include another symlink dir: LIBDIR/firefox/plugins. Also a comment explaining a memory thing. I bet someone down the line who updated this patch messed this up. - If the plugin has a system-wide plugin (NO! Debian's version has this correct. Granted, the string comparison is also sketchy, but this is simply wrong.), we are on Debian, and --nosymlink was not passed, - Add a symlink to the plugin. Same note about existing symlinks as before. - And, as in Debian, remove the symlinks if they exist. - The same NSPLUGIN_DIR patch. - With one modification: if NSPLUGIN_DIR is set, do not install symlinks. This is kind of a hack; they may as well pass --nosymlink when they do this. - This logic is used to redirect the wrapped Flash plugin and setup alternatives or so. I'm not convinced this logic actually works: - If the user installs nspluginwrapper on i386 because they want to run a ppc plugin (as if those exist), then Flash will be incorrectly wrapped. - If a user installs nspluginwrapper on i386 after they first installed Flash, Flash will not be wrapped with nspluginwrapper until the next time Flash upgrades, which is just weird. - nspluginwrapper's update process will at some point try to update Flash and does not know to use NSPLUGIN_DIR. This will go through other codepathes. - This almost never happens because nspluginwrapper also won't update wrappers until the ident string changes which only happens on upstream version bumps. (As a corollary, upgrades with distro patches which change the wrapper half will break. At least on Ubuntu/Debian. Maybe Fedora's thing does something else.) - Pull a list of directories from $NSPLUGIN_DIRS and stick them in with get_mozilla_plugin_dirs. - Flash installs one of these that points to /var/lib/flashplugin-installer, where the npwrapper lives. This presumably is so Flash is handled in updates, except I don't think it works; see above. - install_plugin gets called, which actually dumps the new plugin in a different directory. upgrade_plugin should probably actually call do_install_plugin so the new one goes in the same directory. I suspect the next time Ubuntu updates nspluginwrapper such that the ident string changes, hilarity will ensue.