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

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

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

就像在 Windows 下，不少软件也有安装版与免安装版同样，在 Linux 下也有这样的差异。

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

Windows 下的安装版软件在安装时须要管理员权限，它会在系统的注册表中添加关于本身的信息，也可能会在系统的某些某些地方添加一些文件。通常而言，这样的软件都会在安装目录下提供一个名为uninstall.exe的文件，它会逆向执行安装操做。（这里存在的问题是，这个 uninstall.exe 真的能把软件卸载干净么？因而就产生了各类问题。）
相对的，Linux 的包管理工具，（常见的有apt/dpkg yum/rpm）也须要 root权限，安装时会将软件的依赖、安装位置等信息写入某个地方，在卸载时会执行安装的逆向操做，不过通常只卸载软件自己，而不会卸载依赖。使用 apt 的话，须要用 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 系的软件有以下特点：

1. Linux 系的开源软件，若是是用户群少的或者更新很快的，可能只会发布源码tarball，须要自行编译安装，不会发布各平台的编译版。即便有编译版，也可能只会提供 deb rpm 这样用户群大的，还可能不会及时更新。（Linux 社区崇尚开源，这和之前的 WIndows 大相径庭。不过这也使 Linux 的软件安装过程受人诟病）
2. 用户群大的商业软件，如 Jetbrains 系，只发布通用的二进制 tar.gz 包，也就是免安装版，而 Oracle JDK 则只发布 tar.gz 和 rpm.（大概考虑到不少 CentOS 服务器有用 JDK 吧）
3. 用户群大的开源软件，通常会提供 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 时，一般有两种作法：

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

   举例来讲，安装一个软件时，若是该软件你们都要用，就应该写入系统配置里，而后若是你基本只用 bash，写 bashrc 里更方便(修改可当即生效)，不然选profile。
   而若只有你我的须要该软件，确定要放用户配置里，再考虑你是否是用其余 shell。通常来讲放 bashrc 里总没问题，而放 profile 里，有时会须要手动 source /etc/profile 一下才能用。

2. 第二种呢，就是向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 和 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 脚本。并且经常使用的脚本更新都很及时，这真的超棒！

参考

• 第二十一章、軟體安裝：原始碼與 Tarball
• 怎么卸载用 make install 编译安装的软件？
• Understanding Linux configuration files