[Pkg-mozext-maintainers] [proposal] XUL Extensions policy additions

[Daniel Kahn Gillmor]

On 11/16/2009 06:27 PM, Mike Hommey wrote:
> First, I'd like to relax the location of the extensions files
> themselves. Let's say they can be anywhere, as far as there are proper
> symbolic links in the appropriate places under
> /usr/{lib,share}/mozilla/extensions.
> 
> Second, I'd like to reaffirm that the extensions files should also be
> available in /usr/{lib,share}/mozilla/extensions/common/em:id, except
> for extensions that support only one application (think langpacks,
> mostly), which should use /usr/{lib,share}/mozilla/extensions/app-id/em:id.
> 
> Third, that it's discouraged, though not formally forbidden, to put
> files outside /usr/{lib,share}/mozilla/extensions, especially
> considering that:
> - If an extension is for one application only, there only needs to be
>   one location under /usr/{lib,share}/mozilla/extensions. It's pointless
>   to make it a symlink to somewhere else.
> - On the long term, extensions that are shared between applications are
>   going in a single location, to, in which case it's also pointless to
>   make that single location a symlink to somewhere else. Which is why we
>   encourage such extensions to use the
>   /usr/{lib,share}/mozilla/extensions/common/em:id directory as their
>   canonical location.

These points all seem legitimate to me.  What we're saying with the
three points above is something like: extensions SHOULD be deployed in
/usr/{lib,share}/mozilla/extensions/common/${em:id}, and MUST be
symlinked from that location if they do not reside there already.

> Finally, I wonder if we don't actually need to allow some extensions
> (I'm actually thinking about langpacks) to install directly under
> /usr/lib/appname/extensions. The fact is, we may have 3 different kinds
> of extensions instead of 2:
> - Extensions that work in several applications
> - Extensions that work in one application whatever its branding is
> - Extensions that work in one application and depends on its branding
> IIRC, langpacks *do* include branding. To take an example, iceweasel and
> firefox share the same application id, which is something you'd want, by
> design. But the problem is that if we'd install iceweasel langpacks in
> the /usr/share/mozilla/extensions/iceweasel-appid, firefox would also be
> getting these extensions, that could very well rename some items from
> Firefox to Iceweasel, which is kind of unexpected.
> But maybe I'm just being overzealous, here, and we needn't care.

Ugh.  This sounds likely to be correct to me, though i've never dug into
the details of the langpacks or other branding-specific add-ons.  Is
there no way for a langpack to say internally "i'm only for iceweasel,
not for firefox"?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mozext-maintainers/attachments/20091120/a3b1cc05/attachment.pgp>