Hi again, Jonathan Nieder wrote: > Brandon wrote:
> > The flawed rationale was to have up-to-date plugins for home-folder > > installations of firefox > As far as I can tell from the source, firefox 3.5.9 looks at > /usr/lib/mozilla/plugins, too[1]. For your task, it seems there is no need > of symlink at all. Jonathan Nieder wrote: > Summary: the search path is > > $MOZ_PLUGIN_PATH > ~/.mozilla/plugins > /usr/lib/firefox/plugins > /usr/lib/mozilla/plugins Based on my reading of the source, your analysis is precise and correct. If I remember correctly, my (again, flawed) rationale was that older versions of a plugin in /usr/lib/firefox/plugins (or $MOZ_PLUGIN_PATH or ~/.mozilla/plugins) might take precedence over newer, dpkg-managed versions of the plugin in the /usr/lib/mozilla/plugins folder. I think at the point I initially created the symlink, there were older versions of the plugins in /usr/lib/firefox/plugins, and a better strategy would have been either to check the firefox source or to (re)move the plugins not managed by dpkg and see if firefox used the /usr/lib/mozilla/plugins folder plugins. Jonathan Nieder wrote: > Could you say more about how this symlink arose? I have faint memories of such a symlink long ago, but it’s been a while since I used Firefox. Jonathan Nieder wrote: > Still, I do faintly remember the symlink (from years ago now), so it could make sense to tolerate old systems that include it for old reasons. I don't specifically recall such a symlink on my system, but it's possible that an old version of the firefox browser package would create such a link before Debian migrated to the iceweasel package. Jonathan Nieder wrote: > > To be clear, adobe-flashplugin creates the folder, which I replaced with a > > symlink, but gecko-mediaplayer also creates that folder. > dpkg will never replace a symlink with a directory or vice-versa[2]. > The problems here come because /usr/lib/mozilla/plugins/foo and > /usr/lib/firefox/plugins/foo are the same. dpkg is happy to replace files > from one package when unpacking a later one, and until recently, it would > also replace files unpacked earlier by files unpacked later within a package. What I meant to say was that gecko-mediaplayer also uses that folder, in the sense of creating it if it does not already exist and replacing the files in it. The irony is that, in trying to keep plugins up-to-date and dpkg-managed for home-folder installations of firefox, I did not notice that the older version of dpkg was creating self-referential links and thus eliminating the plugins altogether! Jonathan Nieder wrote: > Hope that helps, Thank you for your help. I would consider delving into firefox source code to check an assumption on a wishlist bug reassigned to a different package to be above and beyond the call of duty, especially when a simple dpkg database search before creating the symlink could have averted this situation. In the future I'll make sure to check the strace when a debug log doesn't provide a definitive answer to a problem. Brandon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
