Linux 的软件管理及配置 - 安装、卸载、升级、依赖

1. 对比：Windows 和 Linux 上软件的安装与卸载

大部分 Linux 使用者都是从 Windows 转过来的，先对这俩做个对比，有助理解。

就像在 Windows 下，很多软件也有安装版与免安装版一样，在 Linux 下也有这样的差别。

1.1. Linux 的包管理工具（rpm/yum、dpkg/apt-get）

Windows 下的安装版软件在安装时需要管理员权限，它会在系统的注册表中添加关于自己的信息，也可能会在系统的某些某些地方添加一些文件。一般而言，这样的软件都会在安装目录下提供一个名为uninstall.exe的文件，它会逆向执行安装操作。（这里存在的问题是，这个 uninstall.exe 真的能把软件卸载干净么？于是就产生了各种问题。）

相对的，Linux 的包管理工具，（常见的有apt-get/dpkg yum/rpm）也需要 root权限，安装时会将软件的依赖、安装位置等信息写入某个地方，在卸载时会执行安装的逆向操作，不过一般只卸载软件本身，而不会卸载依赖。使用 apt-get 的话，需要用 autoremove 选项，这样卸载时，也会自动卸载依赖。（从软件仓库在线安装和下载 deb rpm 离线安装都属此类）

关于依赖(个人揣测）：Winodws 是低耦合设计，官方运行时库全部打包成Microsoft Visual C++ 20xx ，其他依赖一律打包进软件本身。因此基本没听说过依赖管理这样的说法。而 Linux 是高耦合度的设计，好处是可以高度自定义，不需要的东西都可以移除。但是这种环境下，依赖管理就变得很重要。

1.2. 免安装二进制 tarball

而免安装软件呢，Windows 和 Linux 都差不多。只需要将软件解压（下载好的软件应该是 tar.gz 或 zip 格式，需要解压），就能直接用了。

这种 tarball 一般是静态链接进了它本身所有的依赖，因此能实现多发行版通用。

免安装软件需要用户自己记住安装位置，要删除的时候，直接删除掉解压出来的文件夹就行了。（如果使用程序时，它没执行过其他操作的话。）

1.3. Linux 和 Windows 用户的使用习惯

Windows 的用户群大，安装版软件最流行，这种方式能方便用户管理自己安装的软件。而且 Windows 软件体系的兼容性做得特别好，十年前在 Xp 上编译的软件，很可能仍然能在最新的 Win10 流畅运行。（这也是形势所迫吧，在 Windows 上，让普通用户去从源码编译几乎是不可能的，因此开发者别无选择，只能发布 exe 格式。）

而 Linux 系推崇开源，因此一般不会预装任何非开源的软件。如果需要这类非开源的软件，用户只能自行安装。而且 Linux 的软件兼容性远不如 Windows，很多二进制包，在不同发行版、甚至同一发行版的不同版本之间，都是不能通用的。

1.4. Linux 系的软件有如下特色：

Linux 系的开源软件，如果是用户群少的或者更新很快的，可能只会发布源码tarball，需要自行编译安装，不会发布各平台的编译版。即使有编译版，也可能只会提供 deb rpm 这样用户群大的，还可能不会及时更新。（Linux 社区崇尚开源，这和以前的 WIndows 截然不同。不过这也使 Linux 的软件安装过程受人诟病）
用户群大的商业软件，如 Jetbrains 系，只发布通用的二进制 tar.gz 包，也就是免安装版，而 Oracle JDK 则只发布 tar.gz 和 rpm.（大概考虑到很多 CentOS 服务器有用 JDK 吧）
用户群大的开源软件，一般会提供 tar.gz 的源码和 binary.tar.gz.

总结一下就是，Linux 方面，通用的免安装包好像很流行，而安装包只能用于特定发行版，不太讨喜。另外很多工具作者偏爱使用 Python/Nodejs，这类工具不需要编译，可直接使用 pip/npm 安装。

使用 Linux 的大部分都是程序员，因此源码版也很受欢迎。从源码安装有更大的自由度，编译出的程序也可以特定于自己的电脑，省去很多兼容性的东西。简单的说就是更快更爽。

那下面就分这三种情况，分别讨论软件的安装、卸载、依赖管理等。

2. 免安装二进制tarball

这种包一般是 tar.gz 或 tar.xz 格式，解压后，cd 到 bin 目录，里面会有一个与软件同名的脚本或可执行文件，直接运行它就启动软件了。而且这种包貌似是能在各发型版上通用的（eg. pycharm nodejs jdk etc.）

一般我们在 Linux 上安装了软件后，都希望能够在 shell 里直接启动它。要做到这个，需要先了解 Linux 的 shell 环境变量配置文件

全局环境
- /etc/profile 系统的 shell 环境配置文件（仅每个用户登录时加载一次，不建议修改）
- /etc/bash.bashrc 系统的 bash shell 环境配置文件（每次开启一个新 bash，都会加载。如果需要对所有用户都生效的 bash 环境，就修改这个）
用户环境
- ~/.profile [也可能是 ~/.bash_profile] 用户个人的 shell 环境配置文件，相当于 /etc/profile 的个人 patch。一般来说它设定一些用户个人的环境变量，然后执行 ~/.bashrc。
- ~/.bashrc 用户个人的 bash shell 配置文件（同样每次开新 bash 都会加载）
source ：在当前 shell 中执行指定的 shell 脚本。常用于环境设定档。（这样做，运行后的变量会存在于当前shell，也就完成了所谓的环境设定。而如果是普通的直接运行的话，会启用新shell来运行该脚本，运行结束环境就销毁了。）

由上述配置文件引申，用户安装二进制 tarball 时，通常有两种做法：

一种就是将该软体的 bin 目录添加进PATH中（这会使该 bin 目录中的所有可执行文件都被加入到 PATH，如果你不想这样，请考虑第二种方法），也就是将相关命令写入 shell 配置文件中。至于应该添加到哪里，看了上面的说明，你应该已经懂了。

举例来说，安装一个软件时，如果该软件大家都要用，就应该写入系统配置里，然后如果你基本只用 bash，写 bashrc 里更方便(修改可立即生效)，否则选profile。

而若只有你个人需要该软件，肯定要放用户配置里，再考虑你是不是用其他 shell。一般来说放 bashrc 里总没问题，而放 profile 里，有时会需要手动 source /etc/profile 一下才能用。
第二种呢，就是向PATH默认就会包含的那些目录中（例如 /usr/local/bin），添加启动脚本。（使用 python 或 shell 编写）Jetbrains 家的软件在检测到该软件的 bin 目录未添加进 PATH 时，就会提示你这么干。（idea 会向 /usr/local/bin 添加名为 idea 的 python 启动脚本）

而如果是安装 JDK，这之后你还需要手动配置 JAVA_HOME、并将其 bin 目录加入 PATH.

3.使用安装包安装

这种方式就和 Windows 的安装包类似，但是该安装包只能用于特定的发行版，因为不同的发行版使用不同的包机制。最常见的是dpkg 和 rpm，它们也存在对应的在线安装机制，就是apt-get 和 yum.

待续

4. 从源码编译安装

从源码编译安装好处已经说了，自由度更高，兼容问题更少，性能更高等。缺点就是编译比较麻烦，而且安装好的软件也不好管理。

gcc 编译套件（编译 + 链接）

说到编译，一般都是 c/c++ 源码，那在详细说明之前，这里有些目录需要先介绍。

/lib、/lib64：共享链接库，包括静态链接库 *.a，和动态链接库 *.so. 使用 gcc 编译时，默认会从这里查询需要的链接库。不在此列的链接库需要用 -l单个链接库 或 -L/链接库所在文件夹 来指定。
/usr/include：系统头文件的保存处，使用 gcc 编译时，默认会从这里查询需要的系统头文件。不在此列的头文件目录需要使用-I/头文件所在文件夹来指定（是大写的 i）

make 软件构建工具

在软件变得庞大时，如果还手动地一次次调用 gcc，就变得不太现实了。这个时候为了让计算机自动化地处理这种项目的编译构建过程，make 诞生了，它依赖 Makefile。（如果项目变得更庞大，即使是手写Makefile也变得很困难，这时出现了cmake。cmake是用来自动生成Makefile的，它依赖于 CMakeList.txt）

不过流行的开源软件，makefile.txt 的生成规则早就已经写在 configure 里了，你需要做的只是

./configure  --prefix=/home/myname/apps

make

sudo make install

其中的--prefix指定软件安装位置。一般都建议指定，方便管理。（P.S. 被其他软件依赖的包，可能使用默认位置更方便，不然你安装上层软件时会比较麻烦。）安装前都建议先configure --help 一下，仔细看看 help，免得出问题。

如果使用的是cmake，那就用cmake .替换掉./configure就行。（有时为了隔离编译相关文件和源码，会先创建一个build文件夹，再在该文件夹内运行cmake ..）

话虽如此，还是需要先安装好编译需要的依赖，才能正常编译，否则在./configure这一步就会报错。要从源码安装一个软件，最痛苦的不是在make，而是在处理依赖。要是这依赖的安装也能自动化就好了。。。

源码安装软件的删除

从源码安装的软件虽有诸多好处，但是软件的管理就有点麻烦。首先很多的软件作者都不会提供相应的make uninstall 命令，因此这么卸载软件并不通用。

在使用 make install 安装好软件后，一定要记得备份安装生成的install_manifast.txt，再删除掉源码。（这个文件一般会有写保护）

这之后，如果需要卸载，直接xargs rm < install_manifest.txt 就行了

可以创建一个备份目录，专门备份和系统有关的的资料，/etc 和上述的 install_manifest.txt（建议改名为「软件名_install_manifest.txt」）都可以算作此类。

软件的配置

用 Windows 时我们都习惯 GUI 配置界面，（配置会自动写入注册表）而在 Linux 上，因为 CLI(Command Line Interface) 的流行，配置基本都通过修改配置文件来实现，因此了解配置文件的位置就变得很重要。

虽然软件开发者可以自由选择配置文件的位置，不过有约定俗成的规矩：一个软件的配置文件，一般会有三份。分别在：

- `/etc/appname.conf` or `/etc/appname/appname.conf`  # 系统层配置，软件的默认配置，更改需要root权限。一般不建议修改

- `~/.config/appname/appname.conf`                       # 以下都是用户配置，自定义配置。

- `~/.appname/appname.conf`

- `~/.appname_xxx` or `~/.apprc`   # eg. bash vim

分层配置文件，使软件的配置更灵活。一般需要修改配置的时候，就修改~/.config/appname/appname.conf就行了。

画外

最近在包管理工具、构建工具上的思考还挺多的。前几天才学了下 Python 的 pipenv，今天又了解了一下 make/cmake，我突然发现它的依赖处理好像更坑？而还要手动备份 install_manifest.txt......

Arch 的 Pkgbuild 与 AUR 仓库

前面说到 yum/apt 都智能用于管理 rpm/deb 这样特殊格式的包，而免安装 tarball 和源码编译安装的包都只能自己手动管理（更新、删除等）。尤其是源码编译，还需要自己先安装好各种依赖。

如果你有洁癖，编译完成后你可能会想删除掉所有编译时依赖，那你还要手动一个个删除掉这些编译时依赖，可要小心别把运行时依赖给删掉了。。

Arch 就避免了这样的弊端（也许 gentoo 也是，不过没玩过），它使用 pkgbuild 来管理其他来源的安装包/源码包，一键安装，自动处理编译相关的事务。通过一个公共的 AUR 仓库，所有用户都能上传/使用别人写好的 build 脚本。而且常用的脚本更新都很及时，这真的超棒！

参考