原文链接

2010 年开始正式接触 Linux，入门发行版是 Ubuntu 10.10，后来过渡到 Ubunu 11.04， 这其中也尝试了很多其他主流的发行版。进入实验室之后，开始用 CentOS 5，然后是 CentOS 6，现在进化到 CentOS 7。

使用了四年的 Linux，前三年都是在瞎折腾，浪费了不少时间，也得到了不少经验与教训。 现在可能是真的老了，已经不愿意折腾了，只希望配置好一个系统之后，就一直使用下去。

为什么要写/读这一篇

使用 Linux 尤其是 CentOS 会遇到一些坑，或是一些有洁癖的人不能忍的事情：

1. 官方源中的软件包版本太老，在功能上无法满足需求；
2. 多个源的软件包存在版本冲突；
3. 手动编译软件，默认会将不同文件放置在 /usr/local 下不同的子目录下，使得软件的更新和删除变得麻烦。
4. 等等…

在经历了几次重装 CentOS 之后，特总结出如下几条软件安装的方法与原则，以尽可能保证当前系统的稳定、整洁，尽可能降低系统洁癖引起的重装冲动。

以下所说，仅限于 CentOS7，对其他发行版，或许有借鉴意义。

官方源

CentOS 自带的四个官方源中，默认打开的有 base、updates、extras，这三个源中包含了约 9000 个软件包，是最稳定、也是最值得信赖的源。

因而若一个软件包在官方源内，则应通过官方源安装:

sudo yum install PackageName

第三方源

官方源虽然包含了很多软件包，但无法满足日常需求。幸好有第三方源，可以作为官方源的补充。

在使用第三方源的过程中，最怕遇到这两个问题：

1. 第三方源和官方源中有相同的包，导致官方源的包被第三方源替代；
2. 多个第三方源中存在同一个软件包，且版本不一致，存在冲突；

这两个问题经常是致命的，出现各种预料不到的后果，因而选择第三方源要遵循如下原则：

1. 只选择可靠的第三方源，要确保第三方源不会替换官方源中的包；
2. 使用尽量少的第三方源，以保证第三方源之间不会冲突；

就 CentOS 而言，根据以上的原则，使用如下第三方源：

1. 大型第三方源，已确认不会替换官方源的包，且相互之间无冲突
   1. EPEL：包含 6500 多个软件，科研必备
   2. ELRepo：包含几十个各种硬件的驱动程序
   3. Nux Dextop：多媒体相关的软件包（与 EPEL 的个别软件相冲突，可忽略）
2. 有些小型第三方源，仅包含了几个软件，确认与官方源和 EPEL 源不会冲突，也可以添加
   1. Google Chrome：包含了 Google Chrome，不会与官方源和 EPEL 源冲突；
   2. Adobe：仅包含 flash 插件，已确认不会冲突；
   3. dropbox：仅包含 dropbox 一个软件，已确认不会冲突；

因而，若一个软件包位于 EPEL、ELRepo 中，或一些小型的第三方源中，则添加该第三方源，并用 yum 命令安装:

sudo yum install PackageName

官方 rpm 包

大部分非开源的软件，在 CentOS 官方源或 EPEL 中是没有的。有些软件的官方网站会提供官方 rpm 包。此时可以从官方网站下载与当前系统对应的 rpm 包，直接用如下命令安装:

sudo rpm -i PackageName.rpm

比如，WPS for Linux 就是其中一个。在安装的过程中 rpm 命令会自动检查依赖关系，若该软件所依赖的包在官方源和 EPEL 源中可以找到，则自动安装。

直接安装 rpm 包的做法相当省事，但该软件不能由 yum 更新，稍稍麻烦一点。有些软件，比如前面提到的 Google、Dropbox 和 Adobe 其实也可以通过这种方法安装，在安装的同时会给系统添加源，对于这类软件依然可以很方便的更新与删除。

解压即用

有些软件，官方提供了压缩包，解压之后即可直接运行其中的二进制文件，比如很多 Java 写的软件。这类软件没有给源代码，而是给了可以在当前平台下直接执行的二进制文件。大多数非开源的商业软件都采取这种办法。

1. 比如 sublime_text、pycharm、mendeley、TauP、sac 等，直接解压，然后将解压后的文件夹复制到 /opt 目录下，然后将该软件的 bin 目录加入到 PATH 中即可。
2. 比如 Mathematics、Matlab、intel studio，软件包中提供安装脚本，执行该脚本即可安装；

Linux 下的习惯是，商业软件或第三方软件都安装到 /opt 目录下，这也是大多数商业软件包的默认安装路径，尽量遵循该习惯。

第三方 rpm 包

有些软件，CentOS 源和 EPEL 源中找不到，官方又没有提供 rpm 包，但是其他第三方源提供了 rpm 包。分情况讨论：

• 若该第三方源只包含了很少量的包，且确定这些包与官方源以及其他已使用的第三方源不冲突，则可以添加该第三方源。
• 若该第三方源包含了很多软件，很可能与官方源或 EPEL 源有冲突，则不添加该源
  • 若该软件包没有复杂的依赖关系，则直接安装该源中的 rpm 包；
  • 若该软件包依赖于该第三方源中的其他包，则放弃，寻找其他方法；

第三方包管理器

不同的发行版使用不同的软件包管理器，CentOS 使用 yum，Ubuntu 使用 apt-get。近些年又出现了一些与发行版无关的第三方包管理器，比如 Linuxbrew、Gentoo Prefix、pkgsrc。

Linuxbrew

Linuxbrew 是由 OS X 平台下非常流行的 Homebrew 移植到 Linux 下的。Linuxbrew 可以作为系统自带的包管理器的一个补充。其特色在于：

• 所有软件都安装在 ${HOME}/.linuxbrew 目录下；
• 软件的版本相对很新；
• install、uninstall、info、list、update、upgrade 等功能
• 若库中没有需要的软件包，可以很简单地自己创建 formulae

试用了一下，一个比较坑的地方是，linuxbrew 会自己内部解决依赖问题。比如，我试着通过 linuxbrew 安装 terminator，然后发现 terminator 依赖于Python，尽管系统已经安装了 python，linuxbrew 还是会安装一份 python，又由于 python 依赖于更多的东西，导致又安装了更多软件包在 home 下。而且，linuxbrew 是从源码编译软件的，所以相对来说速度较慢。

编译源码

大部分软件用前面的几种方法应该都能安装上了。如果没安装上，那就得问问自己，真的需要安装这个软件么。如果不是非常必要的话就不要安装啦。如果是必须的软件，那就必须要手动编译了。

常见的源码编译，一般也就是如下几步。当然，具体情况具体对待:

tar -xvf xxxx.tgz
./configure --prefix=/opt/xxxx
make
sudo make install

一般来说，这类软件的默认安装目录都是 /usr/local ，最终文件会被分别放在 /usr/local 的 bin、lib、share、man 目录下。

我个人非常不喜欢这种方式，因为作为一个通过源码编译的软件来说，意味着编译者 要完全负起管理该软件的义务，这样的放置方式会来更新或卸载软件带来很多麻烦。 所以我总是会在 configure 的时候加上 prefix 手动指定安装路径。要卸载该软件就直接删除 /opt 下对应的目录，要更新的话，也可以先删除，再重新编译一遍。这样做稍微麻烦的一点是， 需要手动将该软件的 bin 目录加入到 PATH 中，还有可能需要修改 LD_LIBRARY_PATH。 但是一般来说，需要编译源码的软件很少，所以不会造成太大的麻烦。

编译代码

好吧，其实我不知道该怎么起标题了。。

前一节 “编译源码” 主要针对的是一些大型软件包，这一节 “编译代码” 指的是对一些 专业性很强的小代码包的处理方式。比如有些软件包编译之后实际需要的只是一个 二进制文件，这个时候就没有必要安装到 /opt 了，合适的方式是在自己的 HOME 下 建立 bin 目录，并将其路径加入到 .bashrc 中，然后将编译生成的二进制文件复制 到该目录下即可:

mkdir ${HOME}/bin
echo 'export PATH=${HOME}/bin:$PATH'>> ~/.bashrc

比如我的 ${HOME}/bin 目录下有如下文件：

• distaz ：给出地球上两点经纬度，计算震中距和方位角
• pssac ：在 GMT 中绘制 SAC 文件
• rdseed ：SEED 格式转 SAC 格式
• win2sac_32 、 catwin32 ：Hi-net 网站提供的用于处理 Hi-net 数据的程序
• st ：sublime_text 被安装到 /opt 目录下，在此建立一个软链接，方便在命令行调用 sublime text
• wlt.pl ：校内用于登陆网络通的脚本，在命令行修改网络端口，好 happy
• fk 、 fk.pl 、 syn 、 trav ：Prof. Lupei Zhu 的用于计算合成地震图的程序，源代码有不少，实际需要用的也就这三个可执行文件和一个 perl 脚本。
• matlab ：指向 matlab 的一个软连接；

不要随便什么二进制文件都往 bin 里放，这里只应放一些常用的命令或很通用的工具。

自成系统的软件

有一类软件，其拥有众多模块或包，为了管理这众多的模块，就需要拥有一个自己的模块 / 包管理器。这其中以 TeX、Perl 和 Python 为代表。对于这一类软件，其众多的模块是最大的优势，也是最值得利用的资源，因而我通常会选择手动安装它们，原因如下：

• 系统的源中不可能包含该软件的所有模块；
• 系统的源中该软件的模块的更新要远远滞后于最新版本；

当然，即便是使用系统自带的版本，也依然可以用该软件自带的包管理器来安装模块。但将导致：

• 部分模块用系统的 yum 管理，部分模块用软件自带的包管理器管理；
• yum 安装的模块一般版本较老，软件的包管理器要安装的大多是最新版本；

这一方面会导致模块管理的混乱，另一方面用软件自带的包管理其安装模块时，可能会依赖于其他模块的最新版本，若该模块是通过系统 yum 安装的较旧的版本，则可能导致模块的安装失败。

因而，对于这类软件，一般单独安装，并用各自的包管理器管理模块：

• TeXLive：通过 TeXLive iso 镜像文件安装，使用其自带的 tlmgr 管理包
• Perl：通过 plenv 安装最新版本的 Perl，使用 plenv 自带的 cpanm 安装模块
• Python：通过 pyenv 安装最新版本的 Python，使用 Python 自带的 pip 安装模块

例外

有规则总有例外。

第三方源

mosquito-myrepo 是一个私人维护的源，其中包含了中文输入法、QQ、飞信、为知笔记、有道词典、百度云以及若干音频、视频播放器。我对这个源的态度是又爱又恨，其提供了很多中国人需要的软件，但因为其依赖于除 EPEL 外的其他第三方软件源，进而可能导致包冲突。所以对该源的使用，要保持谨慎。

总结

简单总结一下:

1. 为系统添加 EPEL 源、Nux Dextop、ELRepo 源和个别其他小型第三方源
2. 能够从源中安装的就从源中安装
3. 不能从源中安装的尽量找 rpm 包安装
4. 找不到 rpm 包的就试试 linuxbrew
5. 能不手动编译的就不要手动编译

修订历史

1. 2014-11-23：初稿；
2. 2014-12-01：第三方源中加入 ELRepo 源；
3. 2015-07-14：第三方源中加入 Nux Dextop；