From Fedora Project Wiki

Revision as of 16:29, 23 October 2014 by Orion (talk | contribs)

LibreOffice extension rpm guidelines

  1. Extensions deinstalled with unopkg remove Must have a %postun of 'unopkg list --shared > /dev/null 2>&1' because the actual removal of files is deferred until the next start, so this ensures that this takes place under the control of your rpm on deinstallation.
  2. Extensions Should be both installed unpacked and then registered with 'unopkg --link' where possible to save disk-space. Otherwise during registration of a packed .oxt with unopkg the package is automatically unzipped and the contents copied into a persistent cache directory. Using -link and an unpacked .oxt dir allows this additional copy to be omitted and importantly allows the rest of the standard rpmbuild tooling to determine additional autorequires for a package or find flaws that cannot be seen in the opaque zip case.
  3. Unpacked Extensions Must be installed in a dir called NAME.oxt
  4. An extension should normally just be able to just Require: an appropriate LibreOffice component e.g. libreoffice-core, without a specific n-v-r as extensions use the stable UNO abi which rarely changes, and then only to add extra apis. So unless you require a specific feature of a LibreOffice release there is no need to require a specific n-v-r and force a rebuild on every n-v-r of libreoffice.
  5. extensions Must be named libreoffice-FOO. The location where an extension is unpacked Must be in an arch or arch-independent location depending on if the extension has been written in an arch or arch-independent language. e.g. StarBasic and Java only extensions are noarch and Must be unpacked under /usr/share/libreoffice/share/extensions, while e.g. C++ extensions are arch-dependant and Must be unpacked under %{_libdir}/libreoffice/extensions.
  6. extensions are similar to e.g. xorg video drivers in that there exist proprietary or binary only extensions, but of course normal Fedora rules apply to what extensions can be packaged, i.e. see normal packaging licensing etc. rules. The license Must be acceptable, and the package Must be built from source.
  7. extensions can be written in any language that has a uno binding, e.g. C++, python, java or StarBasic. Consider the additional packaging guidelines of the language that the extension is written in if such guidelines exists.

An example is...

%global extname writer2latex

Name:           libreoffice-%{extname}

Requires(pre):    libreoffice-core
Requires(post):   libreoffice-core
Requires(preun):  libreoffice-core
Requires(postun): libreoffice-core

mkdir -p $RPM_BUILD_ROOT%{_datadir}/libreoffice/extensions/%{extnamt}.oxt
unzip target/lib/%{extname}.oxt -d $RPM_BUILD_ROOT%{_datadir}/libreoffice/extensions/%{extname}.oxt

if [ $1 -gt 1 ] ; then
unopkg remove --shared org.openoffice.legacy.%{extname}.oxt || :

unopkg add --shared --force --link %{_datadir}/%{extname}.oxt || :

if [ $1 -eq 0 ] ; then
unopkg remove --shared org.openoffice.legacy.%{extname}.oxt || :

unopkg list --shared > /dev/null 2>&1 || :