[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-libunistring] libunistring 1.1 ABI and LTV_... variable values
From: |
Bruno Haible |
Subject: |
Re: [bug-libunistring] libunistring 1.1 ABI and LTV_... variable values |
Date: |
Sat, 10 Dec 2022 14:18:47 +0100 |
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