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

[Bruno Haible]

Brian Inglis wrote:
> 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". ;^>

The Windows "DLL hell" problem was caused by the *lack* of versioning. That is,
foobar.dll was copied to the same file location, regardless whether foobar.dll
was from 3 year ago, from last year, or a new release, with or without
interface changes.

We would get into the same problem if too many packages did like I did earlier,
namely to keep the major version number unchanged despite of behavioural
changes.

> 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

I don't think that the whole *transitive closure* of reverse dependencies
need to be retested. While the test suite of GNU gettext was affected
by libunistring data changes, the libpsl behaviour is unlikely to be affected.
I gather this from the description of what libpsl does
  https://rockdaboot.github.io/libpsl/libpsl.html
and the fact that its major version number changes rarely
  
https://rockdaboot.github.io/libpsl/libpsl-Public-Suffix-List-functions.html#PSL-VERSION-MAJOR:CAPS

Likewise, even if libpsl changed significantly, it is unlikely that
this would lead to a major version bump of libcurl, because libcurl
is about network protocols, not about text processing.

So, there is nothing to "catch up" for these packages.

For a distro, I think this means that you should run the test suites
of the *direct* reverse dependencies and see which ones fail (or make
an educated guess, if the package does not include a test suite). For
most of the direct reverse dependencies, I would guess that the result
is that you need to rebuild the package so that it then references
libunistring.so.5 instead of libunistring.so.2, but nothing else
changes during that rebuild.

Bruno