libxmlsec1 is a den of iniquity

[jclulow]

According to XML Security Library News, the XML Security Library 1.3.0 release includes the following changes (trimmed to point out the relevant criminal activity):

• core xmlsec and all xmlsec-crypto libraries:
  • (ABI breaking change) ...
  • (ABI breaking change) ...
  • (API breaking change) ...
  • (API breaking change) ...
  • (API breaking change) ...
  • (API/ABI breaking change) ...
  • (ABI breaking change) ...
  • (ABI breaking change) ...
  • ...
• xmlsec-openssl library:
  • ...
  • (ABI breaking change) ...
  • (ABI breaking change) ...
  • ...
• xmlsec command line utility:
  • (API breaking change) ...
  • (API breaking change) ...
  • ...

Literally no preparation for this has been made:

$ elfdump /usr/lib/libxmlsec1*so | grep SONAME
      [13]  SONAME            0x4ad2              libxmlsec1-openssl.so.1
      [11]  SONAME            0x6706              libxmlsec1.so.1

Sigh.

[jclulow]

I think the rough strategy here will be:

• pick a synthetic SONAME of our own; e.g., libxmlsec1.so.999.1.3 which includes three components: one that makes it clear we're working around past silly behaviour, and then the major and minor version from the upstream repository as apparently a move from 1.2 to 1.3 is allowed to break all the fine crystalware in the shop on the way in.
• build and ship both the existing library and the breaking new library in the package together with appropriate links; probably we could put the old library under a facet so that it could be skipped as required. The compilation link would point to the new library.

An alternative is to move to a package name that includes the major and minor version; e.g., libxmlsec13 or whatever. We'd need to mediate the compilation link and the include files at that point, I think, and the libxmlsec13 package would have to have an optional dependency on a branch version bump of the libxmlsec1 package to get one that doesn't conflict, etc.