From Fedora Project Wiki

(Created page with "== libreOffice extension rpm guidelines == # Extensions deinstalled with unopkg remove '''Must''' have a %postun of 'unopkg list --shared > /dev/null 2>&1' because the actual...")
 
(Deprecate this page.)
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== libreOffice extension rpm guidelines ==
{{OldGuidelinePage|LibreOfficeExtensions}}
== LibreOffice extension rpm guidelines ==


# 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.<BR>
# Extensions '''Must''' be installed unpacked under %{_libdir}/libreoffice/share/extensions. These are termed bundled extensions. Extensions should not be installed as shared extensions i.e. via unopkg --shared<BR>
# 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 or .uno.pkg with unopkg the package is automatically unzipped and the contents copied into a persistent cache directory. Using -link and an unpacked .oxt/.uno.pkg 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.<BR>
# An extension should normally just be able to 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.<BR>
# Unpacked Extensions '''Must''' be installed in a dir called [http://extensions.openoffice.org/servlets/ReadMsg?list=dev&msgNo=142 NAME.oxt, NAME.uno.pkg or NAME.zip] <BR>
# extensions '''Must''' be named libreoffice-FOO.<BR>
# 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.<BR>
# 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.<BR>
# 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.<BR>
# 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.<BR>
# 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.<BR>
# extensions can be written in any language that has an 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.<BR>
# Many extensions are actually architecture independent, but cannot be noarch packages due to libreoffice limitations.  Such packages will generate empty debuginfo sub-packages.  If this is the case, add '%global debug_package %{nil}' to the package.
..<BR>
..<BR>
An example is...<BR>
An example is...<BR>
<pre>
<pre>
%global extname writer2latex
%global extname writer2latex
 
Name:     libreoffice-%{extname}
Name:           libreoffice-%{extname}
Requires: libreoffice-core
 
Requires(pre):    libreoffice-core
Requires(post):  libreoffice-core
Requires(preun):  libreoffice-core
Requires(postun): libreoffice-core


%install
%install
mkdir -p $RPM_BUILD_ROOT%{_datadir}/libreoffice/extensions/%{extnamt}.uno.pkg
install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/libreoffice/share/extensions/%{extname}
unzip target/lib/%{extname}.uno.pkg -d $RPM_BUILD_ROOT%{_datadir}/libreoffice/extensions/%{extname}.uno.pkg
unzip -q target/lib/%{extname}.oxt -d $RPM_BUILD_ROOT%{_libdir}/libreoffice/share/extensions/%{extname}
</pre>


%pre
if [ $1 -gt 1 ] ; then
unopkg remove --shared org.openoffice.legacy.%{extname}.uno.pkg || :
fi
%post
unopkg add --shared --force --link %{_datadir}/%{extname}.uno.pkg || :
%preun
if [ $1 -eq 0 ] ; then
unopkg remove --shared org.openoffice.legacy.%{extname}.uno.pkg || :
fi
%postun
unopkg list --shared > /dev/null 2>&1 || :
</pre>
[[Category:Packaging guidelines]]
[[Category:Packaging guidelines]]

Latest revision as of 20:18, 21 December 2018

Warning.png
This is an old copy of a packaging guideline, preserved here in the wiki while we complete the transition to the Fedora documentation system. The current version is located at https://docs.fedoraproject.org/en-US/packaging-guidelines/LibreOfficeExtensions/. Please update your bookmarks.

LibreOffice extension rpm guidelines

  1. Extensions Must be installed unpacked under %{_libdir}/libreoffice/share/extensions. These are termed bundled extensions. Extensions should not be installed as shared extensions i.e. via unopkg --shared
  2. An extension should normally just be able to 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.
  3. extensions Must be named libreoffice-FOO.
  4. 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.
  5. extensions can be written in any language that has an 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.
  6. Many extensions are actually architecture independent, but cannot be noarch packages due to libreoffice limitations. Such packages will generate empty debuginfo sub-packages. If this is the case, add '%global debug_package %{nil}' to the package.

..
An example is...

%global extname writer2latex
Name:     libreoffice-%{extname}
Requires: libreoffice-core

%install
install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/libreoffice/share/extensions/%{extname}
unzip -q target/lib/%{extname}.oxt -d $RPM_BUILD_ROOT%{_libdir}/libreoffice/share/extensions/%{extname}
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:LibreOfficeExtensions&oldid=530784"