大多数 Linux 软件都打包在 tarball 中。只需几个命令即可编译和安装它们。
我的问题是：我们有用于独立 Debian 软件包的 gdebi，那么为什么没有一个以同样方式安装 tarball 的应用程序呢？为什么这么简单的过程没有自动化？为什么我们必须继续用编译软件的想法来恐吓和赶走新用户？
答案1
这些过程是自动化的。您主要在 .deb 或 .rpm 包中获得它们。tarball 和 .deb 之间的唯一区别（在您考虑的层面上）是编译。tarball 通常包含源代码和 make 文件，而不是预编译的二进制文件（尽管它们有时也包含这些文件）。.debs 是跨多个体系结构预编译的。
这里有一个类比：
.deb 是一辆载着整辆车的卡车。
tarball 是一种卡车，上面载有一箱汽车零件和一本手册，告诉您如何组装零件以制造汽车。
因此，当您从 .deb（或“其他”发行版上的 .rpm）安装某些内容时，您安装的内容与该 tarball 中的内容相同，只是这些工作已经为您完成了。
虽然我不同意 txwikinger 关于进步/退步的观点。tarball 完全没有问题，我经常使用它们来打包代码或屏幕截图、日志文件，或者出于各种原因要发送给别人的东西。我还下载源 tarball 来阅读程序的源代码，这样我就可以知道如果遇到问题会发生什么。
答案2
与其花时间简化 tarball 的安装，不如花时间打包 Debian/Ubuntu 的软件，这样总体上更有利。这不仅可以增强基于 Debian 的发行版（如 Ubuntu）的功能，还可以正确安装依赖项
答案3
tarball 通常具有高度可定制性。尽管其中 90％ 只需执行 ./configure && make install，但其他一些需要自定义参数，或者在最坏的情况下，它们使用不同的步骤来构建应用程序。
我认为，作为普通用户，您不必处理 tarball。您最好先检查它是否在某人的存储库中。
tarball（作为最终用户的安装方法）的问题在于： - 如果出现问题，您需要非常精通技术才能快速修复它 - 不一定遵守 disto 的文件夹结构 - 并不总是能够轻松地再次卸载软件。
对于您的第二个问题：是的，这个过程是通过 debian-source 包或 rpm-source 包自动完成的。但这些都不是问题，我认为它们可以在 gdebi 中打开。我不确定您是否知道，但 tarball 是开发人员将他们的代码推向世界的最简单方法。无论他们的项目有多乱，只需压缩源代码并上传即可——这是我所知道的 tarball 的唯一要求：它必须包含某些应用程序的源代码并最终提供构建脚本。
因此，尽管直接使用这些 tarball 是行不通的，但我认为你在这里触及了一个非常重要的问题：Linux 打包很乱。即使对于单个发行版来说，这也是一项艰巨的工作，而对于一个小项目来说，维护各种发行版的软件包几乎是不可能的。
曾经有（现在仍然有）一堆项目试图统一各个发行版的打包方式，但据我所知，这实际上从未取得任何进展。至少没有像 Windows 上的 msi 包或 Mac 上的 dmg 那样常见的包。
我知道这个答案一定令人沮丧，但如果我最近没有错过一场革命，那么这就是我们现在所面临的情况。
答案4
如果您经常这样做，您可以编写一个小的 bash 脚本...
#!/bin/bash
FILE=$1
DIR="${FILE%.tar.gz}"
tar -xzf $1
cd $DIR
./configure
make
sudo make install
将其命名为 tarinstall （或其他名称），将其放入您的路径中，然后执行：
tarinstall thisnewpackage.tar.gz
虽然我确实同意使用像 .debs 或 .rpms 这样的打包系统要好得多。