[gentoo-dev] nsbrowser plugins

[gentoo-dev] nsbrowser plugins

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins.
However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's what
many software projects (including Chromium) target.

Why are we using nsbrowser/plugins instead of mozilla/plugins, and how
relalistic would it be to switch to mozilla/plugins?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] nsbrowser plugins

[Jeroen Roovers]

On Tue, 10 Aug 2010 14:29:20 -0700
"Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:

> Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins.
> However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's
> what many software projects (including Chromium) target.

Could you name them? Opera looks into tons of directories.

> Why are we using nsbrowser/plugins instead of mozilla/plugins, and how
> relalistic would it be to switch to mozilla/plugins?

Index: nsplugins.eclass
===================================================================
RCS file: /var/cvsroot/gentoo-x86/eclass/nsplugins.eclass,v
retrieving revision 1.24
diff -u -B -r1.24 nsplugins.eclass
--- nsplugins.eclass    1 May 2009 23:03:00 -0000       1.24
+++ nsplugins.eclass    10 Aug 2010 23:21:19 -0000
@@ -10,7 +10,7 @@
 
 DESCRIPTION="Based on the ${ECLASS} eclass"
 
-PLUGINS_DIR="nsbrowser/plugins"
+PLUGINS_DIR="mozilla/plugins"
 
 # This function move the plugin dir in src_install() to
 # ${D}/usr/$(get_libdir)/${PLUGIN_DIR}.  First argument should be

You would then need to re-emerge all users of this eclass.

All I want to ask is why? In fact *most browsers* have no trouble
finding plugins, and provide options through which you can inform them
where the plugins might be.

What's bugging Chromium? Why does it insist on using a competing
browser vendor's name instead of the much more neutral "nsbrowser",
which generally denotes browsers with a Netscape style plugin interface?


     jer

Re: [gentoo-dev] nsbrowser plugins

[Mike Frysinger]

On Tue, Aug 10, 2010 at 7:28 PM, Jeroen Roovers wrote:
> On Tue, 10 Aug 2010 14:29:20 -0700 Paweł Hajdan, Jr. wrote:
>> Why are we using nsbrowser/plugins instead of mozilla/plugins, and how
>> relalistic would it be to switch to mozilla/plugins?
>
> --- nsplugins.eclass    1 May 2009 23:03:00 -0000       1.24
> +++ nsplugins.eclass    10 Aug 2010 23:21:19 -0000
> -PLUGINS_DIR="nsbrowser/plugins"
> +PLUGINS_DIR="mozilla/plugins"
>
> You would then need to re-emerge all users of this eclass.
>
> All I want to ask is why? In fact *most browsers* have no trouble
> finding plugins, and provide options through which you can inform them
> where the plugins might be.
>
> What's bugging Chromium? Why does it insist on using a competing
> browser vendor's name instead of the much more neutral "nsbrowser",
> which generally denotes browsers with a Netscape style plugin interface?

indeed.  we've been using nsbrowser/plugins literally for 8 years and
no one has complained.  i dont think "mozilla" is an improvement over
"nsbrowser".
-mike

Re: [gentoo-dev] nsbrowser plugins

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

On 8/10/10 4:28 PM, Jeroen Roovers wrote:
>> Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins.
>> However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's
>> what many software projects (including Chromium) target.
> 
> Could you name them? Opera looks into tons of directories.

Sorry, I used a weasel word "many software projects" without naming
them. I don't know packages other than www-client/chromium that would
have problems with this.

> You would then need to re-emerge all users of this eclass.

I see. This puts some burden for our users with no obvious gains.

> What's bugging Chromium? Why does it insist on using a competing
> browser vendor's name instead of the much more neutral "nsbrowser",
> which generally denotes browsers with a Netscape style plugin interface?

Well, the fact that every distributions chooses its own directory for
NPAPI plugins is sort of sad. The number of directories that have to be
searched for plugins is ridiculously long.

I was talking with Evan Martin, a Chromium developer, and he asked
whether Gentoo could switch to "mozilla/plugins", so I started this
thread. After the results, my patch to add "nsbrowser/plugins" to the
plugins search path is probably going to be accepted.

By the way, I just wonder... why not _symlink_ "mozilla/plugins" to
"nsbrowser/plugins"? That would solve the technical problem, while
keeping a good, more general name.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] nsbrowser plugins

[Mike Frysinger]

On Tue, Aug 10, 2010 at 11:50 PM, "Paweł Hajdan, Jr." wrote:
> By the way, I just wonder... why not _symlink_ "mozilla/plugins" to
> "nsbrowser/plugins"? That would solve the technical problem, while
> keeping a good, more general name.

some plugins like to change their behavior based on the path they're
loaded from ...
-mike

Re: [gentoo-dev] nsbrowser plugins

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 1985 bytes --]

On Wednesday 11 of August 2010 05:50:47 Paweł Hajdan, Jr. wrote:
> On 8/10/10 4:28 PM, Jeroen Roovers wrote:
> >> Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins.
> >> However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's
> >> what many software projects (including Chromium) target.
> > 
> > Could you name them? Opera looks into tons of directories.
> 
> Sorry, I used a weasel word "many software projects" without naming
> them. I don't know packages other than www-client/chromium that would
> have problems with this.
> 
> > You would then need to re-emerge all users of this eclass.
> 
> I see. This puts some burden for our users with no obvious gains.
> 
> > What's bugging Chromium? Why does it insist on using a competing
> > browser vendor's name instead of the much more neutral "nsbrowser",
> > which generally denotes browsers with a Netscape style plugin interface?
> 
> Well, the fact that every distributions chooses its own directory for
> NPAPI plugins is sort of sad. The number of directories that have to be
> searched for plugins is ridiculously long.
> 
> I was talking with Evan Martin, a Chromium developer, and he asked
> whether Gentoo could switch to "mozilla/plugins", so I started this
> thread. After the results, my patch to add "nsbrowser/plugins" to the
> plugins search path is probably going to be accepted.
> 
> By the way, I just wonder... why not _symlink_ "mozilla/plugins" to
> "nsbrowser/plugins"? That would solve the technical problem, while
> keeping a good, more general name.

How about asking Evan Martin (and other browser developers) to add means to 
specify netscape plugin paths for plugin lookup, either as UI element or at 
compilation time. The former is exactly what konqueror provides for instance 
on so it can scan for plugins in many locations (including ~/ for some 
private/local plugins). Hardcoding paths is a bad design™.

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] nsbrowser plugins

[Jory A. Pratt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/10/2010 11:40 PM, Mike Frysinger wrote:
> On Tue, Aug 10, 2010 at 11:50 PM, "Paweł Hajdan, Jr." wrote:
>> By the way, I just wonder... why not _symlink_ "mozilla/plugins" to
>> "nsbrowser/plugins"? That would solve the technical problem, while
>> keeping a good, more general name.
> 
> some plugins like to change their behavior based on the path they're
> loaded from ...
> -mike
> 
> 
Why can chromium not do like firefox and others and make the plugins dir
scalable via a wrapper script. You should be able to pass system plugins
dir from a wrapper script upon launch this is possible in firefox; this
is possible in firefox but easier to just sed the change myself via
ebuild and be done with it.

- -- 
======================================================
Jory A. Pratt                  anarchy -at- gentoo.org
Gentoo Mozilla Lead
GPG: 2C1D 6AF9 F35D 5122 0E8F 9123 C270 3B43 5674 6127
======================================================

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxiLRUACgkQwnA7Q1Z0YSfn9gCePKvoZapicRLFHcTdHKOgYr+w
rZ8AoJqxLVzJXTxOxZpgA3R7E/61uZIx
=OmsL
-----END PGP SIGNATURE-----

Re: [gentoo-dev] nsbrowser plugins

[Luca Barbato]

On 08/10/2010 11:29 PM, "Paweł Hajdan, Jr." wrote:
> Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins.
> However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's what
> many software projects (including Chromium) target.

And that is bad.

> Why are we using nsbrowser/plugins instead of mozilla/plugins, and how
> relalistic would it be to switch to mozilla/plugins?

nsbrowser name is more or less agnostic regarding the current browsers
and probably is due netscape being the originator of this api.

Given it's a path changing it isn't that hard even if IMHO it should be
declared by env var.

lu

PS: what about the user defined plugin dir (yes, it does exist)?

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] nsbrowser plugins

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On 8/10/10 9:51 PM, Maciej Mrozowski wrote:
> Hardcoding paths is a bad design™.

Well, yeah, it could be done better. Hmm, I will think more about it.

On 8/10/10 9:54 PM, Jory A. Pratt wrote:
> Why can chromium not do like firefox and others and make the plugins 
> dir scalable via a wrapper script.

I will ask upstream about that.

On 8/10/10 9:40 PM, Mike Frysinger wrote:
> some plugins like to change their behavior based on the path they're 
> loaded from ... -mike

Could you give an example? I'm just curious. Different distros use
different paths, so that could lead to problems. Or are they trying to
recognize the running distro?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] nsbrowser plugins

[Jeroen Roovers]

On Wed, 11 Aug 2010 07:12:39 -0700
"Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:

> Could you give an example? I'm just curious. Different distros use
> different paths, so that could lead to problems. Or are they trying to
> recognize the running distro?

www-plugins/adobe-flash: https://bugs.gentoo.org/show_bug.cgi?id=328639


    jer

Re: [gentoo-dev] nsbrowser plugins

[Hanno Böck]

[-- Attachment #1: Type: Text/Plain, Size: 840 bytes --]

Am Dienstag 10 August 2010 schrieb Paweł Hajdan, Jr.:
> Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins.
> However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's what
> many software projects (including Chromium) target.
> 
> Why are we using nsbrowser/plugins instead of mozilla/plugins, and how
> relalistic would it be to switch to mozilla/plugins?

The optimal approach would be some kind of standard for things like this. If 
you are already in contact with chromium developers, you might want to start 
such an initiative.

If it would be written in the FHS or something alike, it'd probably be easier 
to convince all browser vendors and distributions to stick to one general 
directory.

-- 
Hanno Böck		Blog:		http://www.hboeck.de/
GPG: 3DBD3B20		Jabber/Mail:	hanno@hboeck.de

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] nsbrowser plugins

[Mike Frysinger]

On Wed, Aug 11, 2010 at 1:04 PM, Hanno Böck wrote:
> Am Dienstag 10 August 2010 schrieb Paweł Hajdan, Jr.:
>> Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins.
>> However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's what
>> many software projects (including Chromium) target.
>>
>> Why are we using nsbrowser/plugins instead of mozilla/plugins, and how
>> relalistic would it be to switch to mozilla/plugins?
>
> The optimal approach would be some kind of standard for things like this. If
> you are already in contact with chromium developers, you might want to start
> such an initiative.
>
> If it would be written in the FHS or something alike, it'd probably be easier
> to convince all browser vendors and distributions to stick to one general
> directory.

here's an idea: nsbrowser/plugins/ is the standard and all browsers so
far support it
-mike