Re: [Pkg-mozext-maintainers] Bits from the Mozilla Extension Packaging Team
2010/2/2 Mike Hommey m...@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. 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? 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? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 m...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-mozext-maintainers] Bits from the Mozilla Extension Packaging Team
Mike Hommey wrote: 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. If your plan is to get it into lintian itself (and I wouldn't see any reason not to do it,) please send it to the BTS (including test cases under t/tests would be great). FWIW, the necessary changes to make it work can be found at: http://bugs.debian.org/562776 Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-mozext-maintainers] Bits from the Mozilla Extension Packaging Team
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. 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. 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. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
