Bug 120329

in addition I would like to request a special subpackage for the plugin, so that
it can be removed easily if wanted by keeping beagle functional.

any progress?

Looks like the code is fine, the max version attribute in install.rdf just needs bumping.  A few users have done this and report that it works fine, so I've committed this upstream.  I'm not sure a chrome.manifest is necessary?

a chrome.manifest is necessary because of two reasons:
1. a extension is required to provide it usually for 1.5 and above
2. We need it to preinstall the extension. We don't want to repeat the dirty
   hack for registration we have in 10.0 as there is the possibility now
   to avoid it. It shouldn't be a problem to create the file correctly.

BTW: please set the maxVersion to 1.5.0.* according to
http://developer.mozilla.org/devnews/index.php/2005/10/17/extension-versioning-in-firefox-and-thunderbird-15/

Ok, I just updated to the 1.5 snapshot we have in STABLE.

I didn't need a chrome.manifest to install the xpi.  It went in fine without it.

So, how do I test it to make sure I do it right?  If it's required for preinstallation, how do I simulate it?

Ah, ok, I found why.  We are shipping a contents.rdf file, which was the way to do things in 1.0 and appears to still work for 1.5.

I'd like to maintain compatibility back to 1.0, so is contents.rdf sufficient or do we also need chrome.manifest?  Moreover, you say that the install.rdf and chrome.manifest have to also be shipped outside of the XPI in /usr/lib/browser-extensions/firefox/{UUID} ?  I'm confused, can you give an example of how the directory should be laid out?

Ok, I just moved the old contents.rdf files out of the way and tested my chrome.manifest.  It's checked in upstream now.

We're going to be doing another Beagle release in the next couple of days, it should be included in there, at which point I can reassign it to you or Gary for packaging.

some background information why we need a chrome.manifest:
In former days it was always needed to register an extension via installing it with the xpinstall mechanism (either by doing it in the application or via command line -register-global-extension).
This is not needed anymore and therefore we don't need any global registration, which is a big step for RPM packaging those applications. (Look at this ugly rebuild-databases.sh stuff and when it gets called in 1.0.x packages)

But the new mechanism does only work if we provide a valid chrome.manifest.
Feel free to provide your contents.rdf along with the extension, because it doesn't hurt and keeps 1.0.x compat.

For the installation in {UUID} it's a simple unzip beagle.xpi which should land
in /usr/lib/browser-extensions/firefox/{UUID} where UUID is the extension's UUID given for example in install.rdf.
You can test if the new-style extension works just by copying this unzipped
tree in /usr/lib/firefox/extensions/{UUID}.
It should just be used if you start Firefox without doing anything else.

*** Bug 134616 has been marked as a duplicate of this bug. ***

Ok, I've updated the package to unpack the XPI into /usr/lib/browser-extensions/firefox/{fda00e13-8c62-4f63-9d19-d168115b11ca} but it doesn't show up in the browser.

I just submitted the updated package to STABLE so you can check it out.

Also, should it be /usr/lib64 for x86-64?

about comment #11: We have to activate scanning of the extension dir first.

about comment #12: the beagle extension has no binaries AFAIK. So it's not important but at the moment we ship Firefox 32bit even on x86-64 and the 32bit Firefox package will use /usr/lib/browser-plugins and /usr/lib/browser-extensions.
Maybe (as long as the extension has no binary parts) we should just create a symlink to make it available on both paths.

Ok, cool.  Reassigning to you.

Reassigning to gekker for now because the beagle package in STABLE still just installs beagle.xpi instead of the unzipped version.

the package unzips the xpi file as part of its postinstall script.

ah, I see. Sorry.
But I see no advantage but only some disadvantages by this approach.
Is there a good reason to do it this way? If not I think it's an example for a superfluous scriptlet in the RPM.

Only that the tarball doesn't include the decompressed XPI.  I'm hesitant to include it as such, since the /usr/lib/browser-extensions/firefox scheme seems to be a suse-specific practice.

The spec file could probably be tweaked to decompress it in the install section and include it, though, right?  I'll defer that to Gary as I am a spec file novice. :)

The path is SUSE specific but not the mechanism to install the unpacked extension.
At least for RPM or integrators needs this is the official way to go.
And yes, it's pretty OK to just unzip it in the install section and copy the directory to the right place.

I've submitted a beagle-firefox package which includes the XPI, compressed and uncompressed.

Reassigning this back to wolfgang.

Extension inclusion is fixed with next Firefox checkin.
The stuff just needs testing now.

sorry, I have to reopen it. While testing it turned out that it isn't possible to include the XPI in the /usr/lib/browser-extensions/firefox directory.
On SUSE Linux we will not need the XPI anyway. If we want to ship it we should move it maybe to some /usr/share/doc/packages/beagle directory.
Otherwise Firefox will ask on every startup to install the XPI and doesn't register the unpacked version at all.

Joe, what do you want me to do with this? Do you want the .xpi installed elsewhere, or nowhere?

We can probably just not ship the XPI file itself at all.

Okay we no longer install beagle.xpi, just the contents thereof.