Estimated read time: 2 minutes
LibreOffice uses a number of external libraries, and most of them can be configured to use a bundled version or a system version. libxmlsec was an exception previously (only the bundled version was usable), but LibreOffice master (towards 6.0) doesn’t have this limitation anymore.
Using a bundled version is a good choice in case:
-
you want to create self-contained binaries
-
you want to bisect a regression, where possibly the regression was introduced by upgrading one of the external libraries
-
the system (e.g. macOS, Windows) doesn’t provide the relevant library
Using a system version is a good thing in case:
-
you want to work with the system, not against it (if a Linux distro already provides libxmlsec, why ship a duplicated copy inside LibreOffice?)
-
being able to use a system version means our bundled version does not have custom patches which affect the functionality of the library
-
not having custom patches also means upstream benefit from our submitted patches, these patches are reviewed by competent maintainers and upgrading the external is easier, as there is no patchset to rebase.
With that in mind, let’s have a look what blocked using system-xmlsec in the past:
-
LibreOffice inherited a large patchset from OpenOffice.org, commit 694a2c53810dec6d8e069d74baf51e6cdda91faa (2012-11-30) had 16 patches, with this scary diffstat:
43 files changed, 5888 insertions(+), 1885 deletions(-)-
I even increased this when I added the SHA256 patches, as back then I wasn’t sure if it’ll be ever possible to upgrade to a newer libxmlsec version.
-
Step by step I got rid of most of these patches, either by upstreaming them or realizing they are no longer necessary. Upstreaming wasn’t always trivial, as for our purposes it was always easy to patch something, but for upstream non-compatible changes always have to be conditional. Today we have 3 build-specific patches, 1 backport and 1 feature patch that is (at least) not necessary when signing / verifying documents with software-based certificates.
-
At the end two more commits were necessary to support building against system-xmlsec, only adding minimal differences when using the system or the bundled xmlsec variants.
If you are a Linux distro packager then --with-system-libs already implies
--with-system-xmlsec, so you probably don’t have to do anything. If you
build LO for static analysis (e.g. Coverity) then this should be also useful,
so not relevant issues in 3rd-party code don’t have to be ignored manually.