我正在努力解决如何处理 Debian Bullseye 和 Debian Bookworm 之间的版本更改。 libicu 从版本 67.x 升级到版本 72.x，这破坏了我当前分发的 .deb 包。当前 .apt 安装失败，因为它在新版本的 Rapsberry Pi Os（可能还有所有 Debian-bookworm 衍生发行版）上找不到 libicu67.deb。
我本质上是一名 Windows 开发人员，所以我不习惯 Linux 版本控制文化。在我看来，操作系统版本的提升会破坏绝大多数现有的二进制文件/安装程序，这似乎很奇怪。所以我希望有人能纠正我。
我使用的是 Raspberry Pi 操作系统，它最近刚刚升级到 Debian“书虫”基础。结果，我的构建和 .deb 包被破坏了。这些中断与 debian 提供的库特别相关。
软件包目前还与 Ubuntu 21.04（以及任何其他基于 Debian Bullseye 的发行版）兼容。我认为 Ubuntu 在某个时候将会有相应的中断。
我试图避免为 Debian-bookworm 和 Debian/bullseye 系统分发单独的 .deb 文件。
我的背景是Windows开发。也许这只是一个 Linux 文化问题；但对我来说，我必须为每个 debian 版本分发预构建的 .deb 文件，这似乎很不寻常。
具体问题：对 libicu（Linux 的 Unicode/本地化服务）的依赖。 破坏的具体依赖关系是：
LibIcU 目前用于 utf-8 <-> utf-32 转换、字符串排序规则和字符串的大写转换。 C++/20 排序规则在 Debian Bullseye 提供的 GCC 10.2 上不起作用。尽管这可能是一条前进的道路。我认为 c++ 20 没有针对区域设置敏感的大写的解决方案。 utf-8 <-> utf-32 转换很容易被替换。我在某处有相关代码。
Libicu 是一个巨大的依赖项（大型数据文件自由地分散在系统中）。所以静态链接确实不是一个选择。
我有点希望 libicu 提供跨主要版本链接的设施，尽管我不辞辛劳地故意破坏 .so 文件名。
可能的选择：
接受这样的事实：我需要分发 4 个 .deb 文件：(Arm/x64) x (buster/bookworm)，除了短期之外，我不知道如何维护它。
运行时绑定到 libicu.so 文件。
只是孤立我所有的破坏者用户，并迫使他们转向书虫（这需要完全重新安装操作系统，这再次让来自 Windows World 的我感到惊讶）。这很尴尬，因为当前版本包含非常重要的升级。
取消实现 libicu 语言环境和 unicode 依赖项。 （现在重新路由到非功能性 GCC 语言环境代码；我有 unicode 转换的代码；只是对大写字母做了错误的事情，目前土耳其语本地化似乎不太可能）。
这实在是太可怕了。我觉得我失去了一些东西。 debian 文件中、链接器中、加载器中的所有版本控制内容，以及 c/c++ 运行时所做的非凡传奇；当我真正需要它时，事实证明它完全故意地依赖于完全基本的库（例如 libicu），尽管到目前为止已经幸存下来的依赖项实际上应该存在噩梦般的版本控制问题。
两个相当重要的开源项目：
我也有同样的问题
libicu我发现.Net只是列出了所有版本。有一个讨论如何进行更好的修复，但我还没有看到任何更新。
有一条 消息提到了
icu您可以查看我的替代 libicu 软件包的解决方法以获取灵感。所有软件包版本最终都位于该软件包的 Depends
文件的
debian/control 部分。
如果您找到更好的解决方案，请分享:)