[Pkg-mozext-maintainers] debian package naming conventions for extensions for mozilla-based tools

[Guido Günther]

On Fri, Jun 26, 2009 at 10:11:18AM -0400, Daniel Kahn Gillmor wrote:
> On 06/26/2009 05:05 AM, Guido Günther wrote:
> > On Wed, Jun 24, 2009 at 12:39:57AM -0400, Daniel Kahn Gillmor wrote:
> >> On 06/23/2009 06:00 PM, Guido Günther wrote:
> >>> Having other distros
> >>> ignore the branding issues with Firefox doesn't help.
> >> to be fair, i don't think the other distributions *have* the same
> >> branding issues as debian.  I fully support the DFSG and the DSC.  That
> > They do AFAIK. The problem is that Mozilla doesn't allow
> > redistribution as Firefox if you patch the source. This is silently
> > ignored by most other distros.
> 
> It's actually not silently ignored.  For example, the Gentoo team spoke
> with MozCorp and got permission:
> 
>  http://bugs.gentoo.org/76920
> 
Reading this, it's simply not helping. Mozilla agreeing once that the
applied patchs are o.k. doesn't mean that it's o.k. in general. This
means Gentoo has to get a thumbs up from Mozilla with every new patch
added. The definition of "Serious Modifications" is very vague.

[..snip..] 
> > We're also prefixing all python modules with python- and all perl
> > modules end with -perl. This makes identifying things a lot easier.
> 
> It does indeed, i'm not opposed to visible naming schemes in general.
> But if we started shipping python as viper when many of our derivative
> distros continued shipping it as python, i'd be reluctant to rename all
> our python modules to viper-* -- i don't know what would be the right
> thing to do in that situation, though, which is why i'm bringing this up.
In terms of trademarks switching to viper-* would probably be the only
choice.

> 
> > It'd say:
> > 
> > <prod>-<ext> if it only covers one XUL based product
> > mozilla-<ext> if it covers several.
> > 
> > I don't see much point in differentiating this further now. If this
> > sound reasonable I'll add this to:
> > 	http://wiki.debian.org/Teams/DebianMozExtTeam
> 
> So if an extension works with both firefox and iceweasel (that's two
> different xul-based packages(?)), it would be named mozilla-<ext> ?  If
> not (if we name it iceweasel-<ext> for debian, do we have suggestions
> for how downstream (firefox-using) distros should work with it?
> 
> For example, if downstream just renamed the package firefox-<ext> and
> rebuilt it, we could get into a situation with conflicting packages: 2
> versions of the same extension attempted to install because they have
> different names, but which both install files into
> /usr/share/mozilla-extensions/<ext>.  so do we suggest a pseudo-package
> instead named "firefox-<ext>" which Depends: on the iceweasel package?

http://www.mozilla.org/foundation/trademarks/policy.html

> 
> As i think through this, there's another option:  Name all the packages
> mozilla-<ext>, and have them place their extensions in
> /usr/share/mozilla-extensons/<ext>  (or /usr/lib/mozilla-extensions, if
> there are arch-dependent components) and provide an iceweasel-<ext>
> metapackage that Depends: on mozilla-<ext> and links
> /usr/share/mozilla-extensions/<ext> into /usr/lib/iceweasel/extensions.
>  Then downstream can have their own firefox-<ext> package, following the
> same convention.
I've been thinking about something similar but without any meta
packages. If we go down but if we go down this path we should make this:

xul-ext-<ext>
or
xulext-<ext>

dropping mozilla from the name meaning it's an extension that serves one
or more xul based applications. I wouldn't use meta packages then but
ship the necessary symlinks in the package itself. Downstream then only
has to add one symlink to debian/xul-ext-<ext>.link (they can still add
a firefox-<ext> package if they want to).

So what about this "policy":

Packages shipping extensions for xul based applications should put them
in /usr/share/xul-extension or /usr/linb/xul-extensions. Using the
former if theres only arch-indep data or the later with arch-dep data.

The extensions should then be symlinked into the applications directory
(e.g. /usr/lib/iceweasel/extensions) for all supported xul applications.

The binary package's name should then be xul-ext-<ext> with <ext> being
the exteonsions name. E.g. xul-ext-nostalgy for Icedove's nostalgy
extension.

In order to ease finding extensions for a given application the packages
should 
Provide: <xul-based-app1>-<extension>, <xul-based-app2>-<extension>
and
Enhances: <xul-based-app1>, <xul-based-app2>

Rationale: 
	* canonical place to look for extensions instead of having them
	  spread across several directories (iceape, iceowl, icedove,
          iceweasel, ...)
        * consistent naming (visual grouping) for all extensions (no
          mozilla-<ext> vs. iceweasel-<ext>)
	* eases automatic packaging of extensions
	* ease work for downstream distributions

Does this make sense? If so I'll add this to the wiki as start of an
extensions policy.
Cheers,
 -- Guido