I'm struggling with how to deal with version changes between Debian Bullseye and Debian Bookworm. libicu bumps from version 67.x to version 72.x, which breaks .deb packages that I'm currently distributing. The current .apt install fails because it cannot find libicu67.deb on the new version of Rapsberry Pi Os (and presumably all Debian-bookworm-derived distros).
I'm fundamentally a Windows developer, so I'm not used to Linux versioning culture. It seems odd to me that a OS version bump should be expected to break the vast majority of existing binaries/installers. So I'm hoping somebody can straighten me out.
Details
I'm using Raspberry Pi OS, which was just recently upgraded to a Debian "bookworm" base. As a result, my builds and .deb packages are breaking. The breaks are specifically releated to debian-provided libraries.
Packages are also currently compatible with Ubuntu 21.04 (and any other Debian Bullseye based distro). I assume there will be a corresponding break on Ubuntu at some point.
I'm trying to avoid having to distribute separate .deb files for Debian-bookworm and Debian/bullseye systems.
My background is Windows development. Maybe this is just a Linux cultural issue; but it seems extraordinary to me that I would have to distribute pre-built .deb files for each debian release.
The specific issue: dependencies on libicu (Unicode/localization services for Linux). The specific dependencies which break are:
- libicu-dev which used to depend on libicu67.deb/libicu68.so, and now depends on libicu72.deb/libicu72.so
LibIcU is currently used for utf-8 <-> utf-32 conversion, string collation, and upper-case conversion of strings. C++/20 collation was non-functional on GCC 10.2 provided by Debian Bullseye. Although that may be a path forward. I don't think c++ 20 has a solution for locale-sensitive uppercasing. utf-8 <-> utf-32 conversion is easily replaced. I have code for that somewhere.
Libicu is a huge dependency (with large data files liberally scattered across the system). So static linking really isn't an option.
I'm kind of hoping that libicu provides facilities for linking across major versions despite having gone to the trouble to deliberately break .so filenames.
Options I'm considering
Possible options:
resign myself to the fact that I need to distribute 4 .deb files: (Arm/x64) x (buster/bookworm), with no real idea how I'm going to maintain that over anything but the short term.
runtime binding to the libicu.so files.
just orphan all my buster users, and force them to move to bookworm (which requires a complete reinstall of the OS, which, again amazes me coming from Windows World). It's awkward because the current build contains very significant upgrades.
De-implement the libicu locale and unicode dependencies. (Reroute onto non-functional GCC locale code for now; I have code for the unicode conversions; just do the wrong thing for uppercasing, turkish localization seems improbable at present).
This is just so truly spectacularly awful. I feel like I'm missing something. All that versioning stuff in debian files, in linkers, in loaders, the extraordinary saga of what the c/c++ runtime does; and when I actually need it, it turns out that it's totally and deliberately borked on completely fundamental libraries (libicu, for example), despite so far having survived dependencies that actually should have nightmarish versioning problems.
Context
Two fairly significant open-source projects: