我正在考虑尝试打包MATLAB（专有软件）适用于 Arch Linux，通过创建 PKGBUILD 来处理安装、依赖关系和冲突。使用标准 Matlab Linux 安装程序，它将所有内容放置在本地目录中，并且不需要许多外部包。
也就是说，它提供了许多标准库文件（例如，libgcc_s.so 和 libstdc++.so）以及完整的 JRE。这些类型的文件是否可以删除（可能用链接替换）并由其他包依赖项提供？
答案1
我不明白为什么删除会成为问题并用链接替换，假设它们与 Matlab 安装中包含的版本相同。但不知怎的，这感觉就像你为自己做了很多工作。
当我曾经支持一个维护许多版本的专有软件包（例如 Matlab）的小组时，我们的小组会将它们安装到独立的目录中并使用类似于modules当用户想要切换用户环境以便可以使用这些包时，维持对用户环境的管理。
请参阅此 U&L 问答，标题为：将同一父目录下的多个子目录添加到PATH中我在其中讨论了管理系统$PATH环境变量的各种策略。这些相同的策略也可以应用于几乎任何环境变量。这些通常是控制专有应用程序功能的因素。
答案2
我尝试为了在 AUR 上维护 PHP App Engine 包，我正在安装它，/opt您应该在其中放置一个独立的 Matlab 包（类似于/opt/matlab），并将可执行文件符号链接回，/usr/bin将其他内容链接回，/usr/share/applications等等。
我会看一下其他一些为 arch 重新打包二进制文件的包。像Dropbox或者谷歌浏览器包。 Chrome 软件包特别依赖于 Debian 二进制文件，因此在 arch 上安装时它们会放弃 Debian 的详细信息。
另一方面，如果您将所有内容/opt/matlab按原样放入，而不是剥离公共库和 JRE，那么您更有可能拥有一个不会损坏或每次都需要重新测试和重新打包的可用 Matlab依赖关系发生变化。
您可以提供两种风格：Matlab 完整包和 Matlab 最小包。
答案3
大型应用程序附带捆绑库有两个原因。原因之一是它使用户不必跟踪所有库、查找哪个包包含其发行版中的库、确保它们具有正确的版本等。维护适用于所有发行版的二进制包是很棘手的，因为在给定点随着时间的推移，发行版通常会提供不同的库版本。如果您的软件包适用于给定发行版的给定版本，那么依赖发行版的版本不是问题。但对于 Arch Linux，由于缺乏稳定的版本，如果您不至少捆绑快速变化的库，您将不得不经常更新您的软件包。
捆绑库的另一个原因是有时程序依赖于特定的库版本。原则上，库有两部分版本号：一个主要版本号，每当 ABI 以不兼容的方式更改时就会更改；以及一个次要版本号，每当任何更改（例如错误修复或不兼容的新功能）时都会更改。破坏向后兼容性）。 （许多库都有 MAJOR.MINOR 形式的版本号，但这不是通用的。）具有不同主要版本的库二进制文件有不同的索纳梅斯，这样它们就可以安装在一起，而仅次要版本不同的库二进制文件具有相同的soname，因此动态链接只能找到一个。如果该程序是针对版本 1.2 构建和测试的，但您拥有版本 1.3，则该程序应该还在工作。然而，有时程序使用未记录的接口，这些接口不是 ABI 的一部分，并且可能在 1.3 中被破坏。由于使用所有可能的库版本组合进行测试将是一场支持噩梦，因此二进制文件的分发者更喜欢所有用户使用相同的库版本（少数系统库除外，尤其是 libc）。
1应用程序二进制接口：编译库和编译程序之间的接口规范。