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

[Brian Inglis]

On 2022-12-09 14:27, Bruno Haible wrote:
> 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.

Hi Bruno,

I can see why that was the case in this version, as a number of (contentious? 
somewhat) recategorizations have taken place, which could impact the results of 
functions dependent on the updated data.

> > 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.

That may also be the case when code points are merely added to blocks, or blocks 
added, and may indicate only a lack of generality in the test suites, not an 
interface change.
I think perhaps that the types of data changes may have to be considered in the 
same way as the types of interface changes, otherwise each release *WILL* be 
considered incompatible with each previous release, and all tests will have to 
be reevaluated in all cases.
Bumping and zeroing ABI implies this breaks downstream interface assumptions, so 
downstreams have to redo all tests and fix all failures.

In reality, we are likely to see downstream package failures as expected 
consequences of interface changes, and if they can be explained, leave it to the 
downstream packages to eventually catch up with their upstream dependencies, and 
fix their test failures.
For example, many libraries depend on libcurl-dev/devel which depends on 
libpsl-dev/-devel which depends on libunistring-dev/-devel, and hundreds of apps 
depend on those libraries, including ubiquities like cmake, git, gnupg, octave, 
R, torrent, weechat, and less obvious packages like TeXlive, etc. but we may be 
unable to wait for app, library, libcurl, or libpsl tests to catch up with 
libunistring interface changes, before releasing updates fixing access or 
security issues.

> > 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.

In most distros, ...so.2 binary package is still required as a runtime 
dependency for older package and app releases built against those older 
-dev/-devel library package releases; new package and app releases will be built 
against the new -dev/-devel library package releases.
That will likely force all packages and apps with a (transitive) runtime 
dependency on unistring to have to be rebuilt with the new release(s), retested, 
tests fixed, and re-released: the Unix version of MS Windows "DLL hell". ;^>

--
Take care. Thanks, Brian Inglis                 Calgary, Alberta, Canada

La perfection est atteinte                      Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter     not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer        but when there is no more to cut
                        -- Antoine de Saint-Exupéry