[Pkg-mozext-maintainers] Policy update

[Benjamin Drung]

Am Montag, den 19.04.2010, 11:51 -0400 schrieb 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.

Yes.

> > 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 appreciate wording improvement. I don't win a price with my English
skills.

> 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.

My wording is far from perfect. My idea was that the extension must be
found in the directory; either by linking symbolically or extracting the
extension there.

> > 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/

k, let's drop it. There is currently no use case for it. We can add it
later if we need it.

> >       * 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

I don't like this idea.

>  * 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).

The debian packager modifications can be done
in /usr/share/xul-ext/fubar/default/preferences/fubar.js in a documented
way.

> 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.

Ok, let's change the "must" to a recommendation. Can we agree on it,
that the /etc/xul-ext/fubar.js contains overrides. Therefore the
overridden values must be defined somewhere else.

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.alioth.debian.org/pipermail/pkg-mozext-maintainers/attachments/20100428/bbc81d15/attachment.pgp>