| 2013-01-31 19:34:44 |
Robert Bruce Park |
description |
[Impact]
At the moment, the jsc-types bindings (needed so that the extension can directly access the C API functions exported by libunity-webapps) are being generated automatically every time one builds the extension by direct parsing of the gir files generated from libunity-webapps.
Part of those exported bindings are some internal functions part of libunity-webapps that are being wrongly exported as symbols along with public parts of the API. This has been fixed in libunity-webapps trunk, where those symbols are not being exported. But now the issue is that we have a chicken and egg problem is we want to release an update of unity-firefox-extension:
- we cannot release a new libunity-webapps version since the already released unity-firefox-extension will look for those missing bindings and break if they are not found,
- we cannot guarantee that releasing both libunity-webapps and unity-firefox-extension the user will install both at the same time, and it is not recommended (to keep packages individually "revertible") to add dependencies between updates,
The idea is to make sure that we can release a new libunity-webapps version (that does not export anymore the private symbols) that won't break the ufe extension. We statically generate the bindings, instead of dynamically then, to have control over what the extension tries to bind with.
The list of bindings is the same as before, just without the private symbols (not used by the extension anyway).
[Test Case]
Verify that the extension works as expected under Firefox:
- opening a integrated website e.g. bbc.co.uk/news or twitter.com
- accepting the integration,
- making sure that an integration happens: launcher icon is there along with some notifications and/or messaging menu integration (in the case of twitter),
[Regression Potential]
None really since we only remove some function bindings that are anyway not exposed/used by the extension. The worst case would be that no integration happens anymore at all. |
[Impact]
At the moment, the jsc-types bindings (needed so that the extension can directly access the C API functions exported by libunity-webapps) are being generated automatically every time one builds the extension by direct parsing of the gir files generated from libunity-webapps.
Part of those exported bindings are some internal functions part of libunity-webapps that are being wrongly exported as symbols along with public parts of the API. This has been fixed in libunity-webapps trunk, where those symbols are not being exported. But now the issue is that we have a chicken and egg problem:
- we cannot release a new libunity-webapps version since the already released unity-firefox-extension will look for those missing bindings and break if they are not found,
- we cannot guarantee that releasing both libunity-webapps and unity-firefox-extension the user will install both at the same time, and it is not recommended (to keep packages individually "revertible") to add dependencies between updates,
Therefore, this update to unity-firefox-extension does not actually change very much that would be user visible; but it is a necessary prerequisite to a larger libunity-webapps SRU that we will be submitting after this one is approved. If this does not get approved, then the libunity-webapps SRU that we need to do will not function at all.
The idea is to make sure that we can release a new libunity-webapps version (that does not export anymore the private symbols) that won't break the ufe extension. We statically generate the bindings, instead of dynamically then, to have control over what the extension tries to bind with.
The list of bindings is the same as before, just without the private symbols (not used by the extension anyway).
[Test Case]
Verify that the extension works as expected under Firefox:
- opening a integrated website e.g. bbc.co.uk/news or twitter.com
- accepting the integration,
- making sure that an integration happens: launcher icon is there along with some notifications and/or messaging menu integration (in the case of twitter),
[Regression Potential]
None really since we only remove some function bindings that are anyway not exposed/used by the extension. The worst case would be that no integration happens anymore at all. |
|
