https://fedoraproject.org/wiki/Mozilla_addons_naming_guideline_draft
Btw. type, components, milestone and version need to be configured in this trac instance.
+1 for the naming.
[[BR]]
I opened up a new ticket for this (ticket #11).
mozilla-noscript (my package) installs two extensions (for firefox and seamonkey), because noscript supports both.
So it might be better to name extensions for mozilla products mozilla-$name (and not just for firefox)...
I suggest to use the following naming convention for firefox plugins and extensions seperately:
Plugin: mozilla-plugin-$name/mozilla-$name Extensions: mozilla-ext-$name
Currently, there are also some firefox plugins in fedora/rpmfusion named as mozilla-$name, so maybe mozilla-$name is not suitable for both plugin and extension, it'll be much better to distinguish firefox addons and extension explictly. If someone readlly like the name mozilla-$name, I think firefox plugins should have a higher priority to usethis naming convertion since installing plugins manually is much more difficult than installing extensions for end users.
Replying to [comment:3 supercyper]:
I suggest to use the following naming convention for firefox plugins and extensions seperately: Plugin: mozilla-plugin-$name/mozilla-$name
Plugin: mozilla-plugin-$name/mozilla-$name
There is no such thing as "Mozilla plugins", I think what you meant is "NPAPI plugins". NPAPI is a common plugin interface which is supported by most web browsers (with IE being a notable exception): Firefox, Chromium, Safari, Opera, Konqueror, Midori, Arora, Epiphany all support NPAPI plugins. Putting NPAPI plugins in the mozilla- namespace would be a misnomer.
My previous message was about plugins, here I'm talking about extensions.
The way Mozilla extensions usually get installed is by dropping files in %{_libdir}/mozilla/extensions/<browser_guid>/<product_guid>/ directory. Each of the Mozilla browsers (Firefox, Thunderbird, Seamonkey, Sunbird, et al) have different <browser_guid>. To install the extension for only Firefox, the extension package has to put its files in mozilla/extensions/%{firefox_guid}/<product_guid>/, to install the extension for all the supported Mozilla browsers the package has to put files in all these browser-specific directories.
For example, to install an extension for both Firefox and Thunderbird an extension package with GUID {00000000-0000-0000-0000-000000000000} needs to put its files in two different directories: %{_libdir}/mozilla/extensions/%{firefox_guid}/{00000000-0000-0000-0000-000000000000}/ %{_libdir}/mozilla/extensions/%{thunderbird_guid}/{00000000-0000-0000-0000-000000000000}/
As the draft says, such a package should be called mozilla-$name. I suppose that means we'll get one package which installs the extension for both Firefox and Thunderbird, right? Should such a package Require both Firefox and Thunderbird?
A quick repoquery revealed that we already have a number of Mozilla extensions. Is the FPC suggesting that all of the following be renamed to mozilla-$name? {{{ $ repoquery -q --whatprovides '/usr/lib64/mozilla/extensions///' mozvoikko-0:1.0-12.fc13.x86_64 mozilla-firetray-thunderbird-0:0.2.8-2.fc13.x86_64 thunderbird-enigmail-0:1.1.2-1.fc13.x86_64 thunderbird-lightning-0:1.0-0.28.b2pre.fc13.x86_64 mozilla-firetray-chatzilla-0:0.2.8-2.fc13.x86_64 beagle-firefox-0:0.3.9-18.fc13.x86_64 mozvoikko-0:1.0-9.fc13.1.x86_64 mozilla-firetray-firefox-0:0.2.8-2.fc13.x86_64 $ repoquery -q --whatprovides '/usr/share/mozilla/extensions///' mozilla-noscript-0:2.0.2.1-1.fc13.noarch mozilla-noscript-0:1.9.9.60-1.fc13.noarch mozilla-adblockplus-0:1.1.3-1.fc13.noarch }}}
I've asked kalev to submit a different draft here, since he has a better understanding of the complexity of the namespace. We'll hold off on implementing this draft (even though it was approved) until we see his counter proposal.
I would like to discuss in today's meeting how to handle installing one extension for multiple Mozilla products.
Most Mozilla extensions tend to work in several products, for examples adblockplus extension is supposed to work in Firefox, Seamonkey, Thunderbird and many more which aren't available in Fedora.
To install an extension for several Mozilla products, the extension has to be copied (or symlinked) into {_libdir}/mozilla/extensions/<browser_guid>/ directories, where <browser_guid> is the UUID of one particular Mozilla product.
Should we have a) a single binary package which installs the extension for all supported Mozilla products, or b) multiple binary packages, one for each supported Mozilla product?
There are pros and cons for each of these.
Sorry, running out of time to write more; see you in the meeting in a few minutes and lets figure out which path to take.
From the Sept. 22 meeting:
16:33:43 <spot> so, we'll revisit this issue when kalev works up that draft for us
I have started working on a draft for packaging Mozilla extensions ![1], but it's still very very raw. As discussed in the meeting ![2], it's going to outline best practices for having a single binary package which registers the extension for all supported Mozilla applications.
![1] https://fedoraproject.org/wiki/User:Kalev/MozillaExtensionsDraft [[BR]] ![2] http://meetbot.fedoraproject.org/fedora-meeting/2010-09-22/fedora-meeting.2010-09-22-16.02.log.html
I do have some remarks in here :
The mozilla prefix in the naming should take place if and only if the addon works on at least two mozilla applications in the repos ( as we don't care about mozilla applications not in our repos ).
Having a single package which enables an addon for several mozilla applications is limiting the user's freedom : IMHO, the user should be able to choose which application he wants to enable the addon for.
The addon should depend on the mozilla application it is working with. If it is working with multiple applications, then a subpackage should be created for each application and depend on it; Having an addon without its application is problematic for two reasons :
It uses a symlink/subdirectory which is located in a directory owned by a mozilla application, but this application isn't installed --> why the mozilla application owns the extension directory then ?
Intuitively, it doesn't make sense to have an addon installed without any application using it.
A new behavior introduced by gecko >= 1.9.2 doesn't allow symlinking the extension directory to another location; instead, an subdirectory must be created and each file symlinked separately. I have this behavior at least with extensions involving binary components.
Replying to [comment:11 hicham]:
I do have some remarks in here : Having a single package which enables an addon for several mozilla applications is limiting the user's freedom : IMHO, the user should be able to choose which application he wants to enable the addon for.
I do not know all mozilla applications, but at least in firefox a user can always select which addons to enable or disable. Also installing the rpm sets a default for the system and not for a user. Therefore being able to disable addons is always needed for cases where the interests of the system admin and user differ.
The addon should depend on the mozilla application it is working with. If it is working with multiple applications, then a subpackage should be created for each application and depend on it; Having an addon without its application is problematic for two reasons : It uses a symlink/subdirectory which is located in a directory owned by a mozilla application, but this application isn't installed --> why the mozilla application owns the extension directory then ?
Directory ownage problems can be solved using -filesystem subpackages, e.g. firefox-filesystem could own the neccessary addon directories that addons can depend on.
One unused symlink on the filesystem does not sound as bad as having to download the same data several times. And it is not unusual to have files installed that are not used, e.g. if packages provide bash completion files but one does not have bash completion installed.
Why has this changed?
Replying to [comment:13 till]:
Replying to [comment:11 hicham]: I do have some remarks in here : Having a single package which enables an addon for several mozilla applications is limiting the user's freedom : IMHO, the user should be able to choose which application he wants to enable the addon for. I do not know all mozilla applications, but at least in firefox a user can always select which addons to enable or disable. Also installing the rpm sets a default for the system and not for a user. Therefore being able to disable addons is always needed for cases where the interests of the system admin and user differ.
What if the extension gets broken for some application ? The sysadmin would then tell all the users to disable it instead of just removing the package.
The addon should depend on the mozilla application it is working with. If it is working with multiple applications, then a subpackage should be created for each application and depend on it; Having an addon without its application is problematic for two reasons : It uses a symlink/subdirectory which is located in a directory owned by a mozilla application, but this application isn't installed --> why the mozilla application owns the extension directory then ? Directory ownage problems can be solved using -filesystem subpackages, e.g. firefox-filesystem could own the neccessary addon directories that addons can depend on.
That is correct IMHO. However next point is still there.
Intuitively, it doesn't make sense to have an addon installed without any application using it. One unused symlink on the filesystem does not sound as bad as having to download the same data several times. And it is not unusual to have files installed that are not used, e.g. if packages provide bash completion files but one does not have bash completion installed.
Data won't be downloaded several times, only symlinks. The packages providing bash completion should ship this in a subpackage and depend on bash completion.
A new behavior introduced by gecko >= 1.9.2 doesn't allow symlinking the extension directory to another location; instead, an subdirectory must be created and each file symlinked separately. I have this behavior at least with extensions involving binary components. Why has this changed?
Ask mozilla.
Replying to [comment:14 hicham]:
Replying to [comment:13 till]: Replying to [comment:11 hicham]: I do have some remarks in here : Having a single package which enables an addon for several mozilla applications is limiting the user's freedom : IMHO, the user should be able to choose which application he wants to enable the addon for. I do not know all mozilla applications, but at least in firefox a user can always select which addons to enable or disable. Also installing the rpm sets a default for the system and not for a user. Therefore being able to disable addons is always needed for cases where the interests of the system admin and user differ. What if the extension gets broken for some application ? The sysadmin would then tell all the users to disable it instead of just removing the package.
The targetted procedure is afaik this: It the extension is broken by an update of some application, the sysadmin catches this while testing the update in updates-testing and reports this back via bodhi. Then the package maintainer of the application in question will fix the update or the addon will be modified to work with the updated application and an update will be created. If both work again, then they are pushed to stable.
If the sysadmin does not care to report breakage because of updates, there is nothing the Fedora project can do about it.
The addon should depend on the mozilla application it is working with. If it is working with multiple applications, then a subpackage should be created for each application and depend on it; Having an addon without its application is problematic for two reasons : It uses a symlink/subdirectory which is located in a directory owned by a mozilla application, but this application isn't installed --> why the mozilla application owns the extension directory then ? Directory ownage problems can be solved using -filesystem subpackages, e.g. firefox-filesystem could own the neccessary addon directories that addons can depend on. That is correct IMHO. However next point is still there. Intuitively, it doesn't make sense to have an addon installed without any application using it. One unused symlink on the filesystem does not sound as bad as having to download the same data several times. And it is not unusual to have files installed that are not used, e.g. if packages provide bash completion files but one does not have bash completion installed. Data won't be downloaded several times, only symlinks. The packages providing bash completion should ship this in a subpackage and depend on bash completion.
There is still lots of meta-data that needs to be downloaded. Splitting off such small files makes it just a PITA to install new packages. E.g. for each package one would need to check for the existence of several sub-packages: bash completion + completion for other shells (e.g. zsh), syntax hightlighting files for each used editor (afaik there are at least gedit, emacs, vim and some kde editor supporting syntax highlighting files), power hooks for pm-utils and whatever I am currently missing.
Replying to [comment:15 till]:
Replying to [comment:14 hicham]: Replying to [comment:13 till]: Replying to [comment:11 hicham]: I do have some remarks in here : Having a single package which enables an addon for several mozilla applications is limiting the user's freedom : IMHO, the user should be able to choose which application he wants to enable the addon for. I do not know all mozilla applications, but at least in firefox a user can always select which addons to enable or disable. Also installing the rpm sets a default for the system and not for a user. Therefore being able to disable addons is always needed for cases where the interests of the system admin and user differ. What if the extension gets broken for some application ? The sysadmin would then tell all the users to disable it instead of just removing the package. The targetted procedure is afaik this: It the extension is broken by an update of some application, the sysadmin catches this while testing the update in updates-testing and reports this back via bodhi. Then the package maintainer of the application in question will fix the update or the addon will be modified to work with the updated application and an update will be created. If both work again, then they are pushed to stable. If the sysadmin does not care to report breakage because of updates, there is nothing the Fedora project can do about it.
I totally agree with what you said. However, here is one more use case I am thinking about : The sysadmin wants to disable the addon for some mozilla application(s), and we only ship one package, what is he supposed to do ?
The addon should depend on the mozilla application it is working with. If it is working with multiple applications, then a subpackage should be created for each application and depend on it; Having an addon without its application is problematic for two reasons : It uses a symlink/subdirectory which is located in a directory owned by a mozilla application, but this application isn't installed --> why the mozilla application owns the extension directory then ? Directory ownage problems can be solved using -filesystem subpackages, e.g. firefox-filesystem could own the neccessary addon directories that addons can depend on. That is correct IMHO. However next point is still there. Intuitively, it doesn't make sense to have an addon installed without any application using it. One unused symlink on the filesystem does not sound as bad as having to download the same data several times. And it is not unusual to have files installed that are not used, e.g. if packages provide bash completion files but one does not have bash completion installed. Data won't be downloaded several times, only symlinks. The packages providing bash completion should ship this in a subpackage and depend on bash completion. There is still lots of meta-data that needs to be downloaded. Splitting off such small files makes it just a PITA to install new packages. E.g. for each package one would need to check for the existence of several sub-packages: bash completion + completion for other shells (e.g. zsh), syntax hightlighting files for each used editor (afaik there are at least gedit, emacs, vim and some kde editor supporting syntax highlighting files), power hooks for pm-utils and whatever I am currently missing.
I don't see the problem with that, AFAIK subpackages are supposed to organize dependencies and allow for more flexibility; ie, the user only installs what he/she wants.
I think that in our case, when a user is looking for a mozilla addon in the repos, he/she expects to find it using for example "yum search <mozilla-application>", which should give all the related packages.
This draft appears to be stale, closing. If there is interest, please reopen.
Login to comment on this ticket.