Re: [Pkg-mozext-maintainers] Bits from the Mozilla Extension Packaging Team
On Tue, Feb 02, 2010 at 12:11:07PM +0100, Benjamin Drung wrote:
> 2010/2/2 Mike Hommey <mh@glandium.org>:
> > On Mon, Feb 01, 2010 at 08:34:31PM +0100, Benjamin Drung wrote:
> >> Hi,
> >>
> >> This mail targets all developers, which maintain Mozilla extensions.
> >>
> >> Source package name
> >> ===================
> >>
> >> The source package name for extension should not contain the name of the
> >> enhanced application. These prefixes should be dropped from the source
> >> name:
> >>
> >> firefox-
> >> iceape-
> >> icedove-
> >> iceweasel-
> >> mozilla-
> >> thunderbird-
> >>
> >> If the remaining string is too generic (for example, notify or sage),
> >> the source package name should append -extension. For example,
> >> firefoxnotify was renamed to notify-extension.
> >
> > I don't remember this has been discussed, and i certainly disagree with
> > this naming scheme. Also, existing extensions sources shouldn't be renamed.
>
> Yes, we only discussed binary names. The same rules apply for source
> package names. Why should Debian have a source package with firefox in
> its name (for example, firefox-notify) and why should Ubuntu have a
> source package with icedove in its name (for example,
> icedove-quotecolors)? This would be similar to the python name scheme.
> For example the source package matplotlib provides the binary package
> python-matplotlib.
I for one think the source should be named with the upstream name.
firefox-notify is the upstream name, I don't see why there would be a
need to change that, even if the name is lame.
> >> Binary package name
> >> ===================
> >>
> >> The Mozilla extension packaging team decided to use xul-ext- (instead of
> >> mozilla-, iceweasel-, etc.) as prefix for all Mozilla extensions [1].
> >> This will group the extensions visually. There are currently 18
> >> extensions that use this naming scheme already. Please rename the binary
> >> package if not already done.
> >
> > Note the policy proposal has not been updated with the latest
> > propositions (for which i was hoping more feedback, btw). See the team
> > list archives.
>
> I read the archives. There are still some parts of the policy proposal
> that needs more discussion (for example the directory question). The
> binary naming part was discussed and we reached the consensus that
> using xul-ext- as prefix is the lesser of the two evils, didn't we?
Yes, but as said in one of my messages there, there are exceptions we
may want to grant, for localizations, for example.
> >> Use mozilla-devscripts
> >> ======================
> >>
> >> To make packaging extensions dead simple we have mozilla-devscripts. In
> >> most cases debian/rules can be reduces to three or four lines (shebang,
> >> two includes and maybe one variable). We highly recommend using it. An
> >> additional benefit of using mozilla-devscripts is that derived
> >> distribution can use the source code without modifying it.
> >> mozilla-devscripts take care of the distributions specialities. The
> >> usage is explained in the Wiki [2].
> >>
> >> Joining our team
> >> ================
> >>
> >> You are welcome to join our team. We maintain all packages in git in the
> >> pkg-mozext group. You can contact us via email or IRC [3]. Please let us
> >> know, if you need help implementing the above mentioned items.
> >>
> >> Work needing package
> >> ====================
> >>
> >> Here is a list of source package that need to updated. Please let me
> >> know, if I missed some packages.
> >
> > I have a lintian check that checks most of the policy, except it was
> > written before lintian 2.3 and doesn't work anymore. If someone has the
> > time to update the script before me, I'll send it to them.
>
> What will be checked by that?
The current tags are:
Tag: xul-extension-wrong-package-name
Tag: xul-extension-missing-provides
Tag: xul-extension-missing-enhances
Tag: xul-extension-in-application-directory
Tag: xul-chrome-in-application-directory
Tag: xpcom-component-in-application-directory
Tag: non-extension-or-plugin-in-mozilla-directory
Tag: plugin-in-application-directory
Tag: xul-extension-incompatible-with-iceape-before-2-0
Tag: file-in-deprecated-var-lib-application-chrome.d
Tag: file-in-deprecated-var-lib-application-extension.d
Tag: deprecated-extension-uninstall
Tag: xpcom-standalone-glue-without-xulrunner-dependency
Tag: contains-xulrunner-stub
Mike
Reply to: