[Pkg-mozext-maintainers] Policy update

[Daniel Kahn Gillmor]

On 04/19/2010 07:06 AM, Benjamin Drung wrote:
> I think we should not specify a install location and drop this
> paragraph:
> 
> Packages shipping extensions for XUL-based applications like iceweasel
> or icedove should put unpack the contents of the extension in a folder
> in /usr/share/mozilla/extensions/common. Packages that also contain
> architecture-dependent material should place the architecture-dependent
> material in a folder in /usr/lib/mozilla/extensions/common and symlink
> to it from the folder under /usr/share/mozilla/extensions/common 

I'm OK with dropping this on the ground that extensions must know their
app-ids anyway, so making the decision of which extensions folder to use
can be done at packaging or installation time, rather than forcing
applications to wade through each "common" extension which might not
apply to them at startup.

> The unpacked extension directory must be symbolic linked into the

if you don't like "symlinked", please replace it with either
"symbolically linked" or "linked symbolically"  -- i'm fine with any of
those three, but "symbolic linked" seems wrong.  sorry for the syntactic
pedantry :P

I'm not convinced by the "must"s in this revision of the second
paragraph, but it is the strategy that i plan to follow myself.  And i
think mike's description of a one-app-extension being placed directly
without a symlink is a good counterexample.  So i'd be fine with the
ideas here, as long as they allow one-app-only extensions to be placed
directly without using a symlink.

> Config Files
> ============
> 
> This section should contain these rules:
> 
>       * config files must be put into /etc/xul-ext/fubar.js
>         or /etc/xul-ext/fubar/ if more than one file is required

As others have said, there doesn't seem to be a good reason to allow for
more than one config file per extension.  drop /etc/xul-ext/fubar/

>       * config files must be empty or contain only comments

I'm not convinced by this.  One reasonable pattern that i can see is:

 * ship upstream's preference files unchanged in
/usr/share/xul-ext/fubar/default/preferences/fubar.js
 * symlink /usr/share/xul-ext/fubar/default/preferences/00_system.js as
a symlink to /etc/xul-ext/fubar.js
 * ship /etc/xul-ext/fubar.js containing debian packager overrides of
preferences (and a comment referring to where to look for other
preferences an admin might want to override).

This makes it clear to an admin (without examining the source package)
what modifications are debian-specific modifications, it makes it easy
to revert to upstream defaults, and it encourages site-specific
modification as well.

	--dkg

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