Re: [bug-libunistring] libunistring 1.1 ABI and LTV_... variable values

[Bruno Haible]

Hi Brian, Daiki,

> > Packaging 1.1 on latest Cygwin, DLL version jumps from 2 to 5.
> 
> This affects not only Cygwin, but also any other distributions where
> libtool supports building shared library.

Yes.

> In the first place, however, is this SONAME bump intentional?

Yes, it was intentional.

The libtool documentation
  
<https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html>
says:
  "If any interfaces have been ... changed since the last update,
   increment current, and set revision to 0."

In the past, when the data tables of libunistring changed (due to a newer
Unicode version), I often had not seen this as an "interface change",
and as a result, for some packages (e.g. GNU gettext) the test suite
started to fail. For instance, GNU gettext has tests which depend on the
output of the line-breaking algorithm, which in turn depends on the
width tables. Probably GNU guile has similar unit tests as well.

In order not to repeat this experience, I added a clarification to
gnulib/build-aux/libtool-next-version:

    Have any interfaces (functions, variables, classes) been changed since the
    previous release? This includes signature changes. It includes also details 
of
    how functions produce their results and the values of variables, IF AND 
ONLY IF
    users of the library are likely use these details in their test suite.
    Please answer yes or no.

So, this time, I answered "yes" on this question, and thus libunistring.so
gets an increased version number.

> In my case it was on
> Fedora[1]; that means we would need to rebuild all the dependent
> packages

Yes, I think this is useful, since the updated libunistring data tables might
cause failures in the test suite of these packages.

> some of which might be required by compose bootstrap, so we
> might eventually need to provide a compatibility package that provides
> both SONAMEs to fix the buildroot. ...
> SONAME changed from 'libunistring.so.2' to 'libunistring.so.5'

I don't understand this, since I'm not a "distro guy". But yes, I understand
that you might have to ship a libunistring.so.2 (based on the source code
of the previous version) for some backward compatibility cases.

Bruno