[Pkg-mozext-maintainers] #573250 -- conflict between policy and mozilla-devscripts about file placement

[Mike Hommey]

On Wed, Mar 10, 2010 at 04:37:18PM -0500, Daniel Kahn Gillmor wrote:
> hey debian mozilla extension packager people --
> 
> i just filed http://bugs.debian.org/573250 about a conflict between
> mozilla-devscripts and our current draft of policy related to the
> directory placement of extensions.
> 
> Our discussion in november 2009 [0] sort of petered out without
> resolution.  Can we align them, so that our policy matches what we think
> of as best practices, and our tools also correspond?
> 
> Here's a proposal for rewording the policy for file placement for xul
> apps (i'm not wedded to it, this is just a trial balloon):
> 
>  0) Architecture-independent packages for extensions to xul apps get
> installed in /usr/share/xul-ext-foo.
> 
>  1) preferably, these packages create a symlink corresponding to each
> supported xulapp at
> /usr/share/mozilla/extensions/<app-id>/<extension-id> , pointing back to
> /usr/share/xul-ext-foo.
> 
>  2) if (1) is not possible, the package should have a single symlink
> placed in /usr/share/mozilla/extensions/common/<extension-id>, pointing
> back to /usr/share/xul-ext-foo ;  each xul-apps will evaluate the
> suitability for themselves of each extension installed this way at runtime.
> 
>  3) architecture-dependent packages unpack the entire extension into
> /usr/lib/xul-ext-foo, instead of /usr/share/xul-ext-foo, but otherwise
> create the same set of symlinks as arch-indep packages.
> 
> 
> What do folks think?  It would be nice to get the tools and the policy
> aligned before we release.

I think we shouldn't clutter /usr/share and /usr/lib with one directory
per extension.

As a side note, I don't think using packed .xpi files should be helped
by the tools, but that the .xpi files should be unpacked and made a
proper source tarball. Also note that some extensions provide .xpt
files, and here I'm sorry to shout but THEY ARE NOT SOURCE FILES. .xpt
files are generated from .idl files. If you don't have them, then it
means you don't have the source and are therefore probably not
respecting the software license. Your upstream may also not provide the
source in which case she may herself be breaching her own license.

Mike