Re: [Pkg-mozext-maintainers] Bits from the Mozilla Extension Packaging Team
2010/2/2 Mike Hommey <firstname.lastname@example.org>:
> On Mon, Feb 01, 2010 at 08:34:31PM +0100, Benjamin Drung wrote:
>> 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
>> 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
>> Binary package name
>> The Mozilla extension packaging team decided to use xul-ext- (instead of
>> mozilla-, iceweasel-, etc.) as prefix for all Mozilla extensions .
>> 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?
>> 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 .
>> 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 . 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?