Subject: Re: mk/plugins.buildlink3.mk (useful for gecko based browser
To: Juan RP <firstname.lastname@example.org>
From: Julio M. Merino Vidal <email@example.com>
Date: 06/19/2004 10:22:54
On Sat, 19 Jun 2004 03:25:46 +0200
Juan RP <firstname.lastname@example.org> wrote:
> What do you think about this? I'm using it locally to use multimedia/moz-mplayer
> with firefox-gtk2.
Aside Jeremy's comments, I have some more...
So, AIUI (and I'm not missing anything), you are forcing the entire system
to only allow plugins for a single browser? What happens in multi user
environments, where each user wants a different browser with plugins
available? (Or even in a single user one... I use different browsers when
I need to.)
What happens with binary packages? They are only useful for a single
browser? How do you choose a reasonable default? (Simply put, you can't;
a browser is a very personal decision.)
This needs a more complex approach to be useful. One I can think of is
the one I explain below (hmm just woke up, maybe it misses lots of details ;)
Start by installing _all_ plugins in some centralized directory that is
not browser dependent. The packages just install the files in it but do
_not_ depend on any browser package. Each package also installs a
small file together it that specifies a list of compatible browsers (or
this could be just a single file containing a line per plugin).
For example, you could have: /usr/pkg/lib/browser-plugins. In this directory
you could find a directory called flash, another called sun13-java, aaand
a file, named 'database' that contains lines like:
flash: mozilla mozilla-gtk2 firefox-gtk2
sun13-java: mozilla mozilla-gtk2 firefox-gtk2
(or a file 'supported-browsers' inside flash, sun13-java, etc that just
contains the list of browsers; sounds easier).
(maybe browser names could be gruped with a single name like 'gecko' or
some such, so that new browsers can be added to pkgsrc without having to
reinstall all plugins).
Then, when installing a browser, you could have to look at the centralized
plugins directory (explained above), read the database(s) file(s), and see
if the plugin is compatible. If it is, symlink into the browser specific
directory. At deinstallation time, simply remove all symlinks.
This sounds simple, but there is one more problem. The above will only
work if you install plugins _before_ browsers (not a common situation).
So the reverse approach is _also_ needed. I.e., when installing a plugin,
it should walk the list of installed browsers and add itself to their
plugin directories (so each browser also needs to install a small file
telling where its plugin database resides, or a single file, just like
the 'database' explained above).
Julio M. Merino Vidal <email@example.com>
The NetBSD Project - http://www.NetBSD.org/