问题是，你要求安装程序知道特定于发行版的东西，比如路径，查看文件及其位置等等，而不想求助于特定于发行版的工具。
我个人至少参与了两种特定于应用程序域的方法来构建这样的通用安装程序，并且知道其他一些方法。
所有的。他们。失败了。
请注意，这不是根本性的，而是提高了通用易用性的水平，从而减少了开发它们的社区的支持工作量。它们在其他方面表现出色-将构建配方保持在一个地方，提供独立于发行版的安装前缀，但它们未能成为轻松，便携，稳定，只需安装软件的低成本解决方案。
这主要源于不同Linux平台上的工具和软件包的差异，以及非标准位置的微小程度。
当您可以依赖于已经安装的所有软件的外部依赖项，大多数库作为软件本身的一部分提供，并且与系统的其余部分没有交互时，事情确实工作得很好。但这最终是一个安装程序，只是解包文件，例如。到/opt/Matlab，而不是你希望的安装程序，尊重一些系统细节和用户设置。
特别是服务的集成曾经有点棘手-我非常高兴systemd为所有严肃的用户群¹结束了/etc/init.d中的随机脚本，这些脚本以难以猜测的顺序（如果你不知道你使用的发行版中的典型顺序）并且不了解依赖关系。（Systemd标准化了很多目标和服务名称，你可以只说你的服务被多用户目标需要但需要工作联网，先启动sssd）
因此，对于依赖项和服务安装，几乎没有办法让用户手动进行一些设置。
对于在依赖关系树中“离开”的应用程序风格的软件，自包含的软件打包是一件事- flatpak可能是最常用的方法。不幸的是，对服务没有那么有用。
¹无论你做什么，你永远无法接触到超过95%的用户。反对systemd的声音用户群非常善于强调它们的重要性。他们是一个边缘群体，不使用systemd;重点支持95%的用户，让1%的特殊兴趣用户在安装后自行采用您的 Package ;他们自作自受，没有权利叫别人去自作自受。
请注意，支持这些用户，但也有95%的人有一些其他的小特殊怪癖总是意味着你应该有“只是提取所有文件到前缀，并告诉用户需要做什么之后，大致”安装模式。这样，发行版Maven、特殊用例和在不可预知的未来使用你的软件的人就不会讨厌你。