CentOS7下的软件安装方法及策略详解
发布网友
发布时间：2023-10-06 23:07
共1个回答
热心网友
时间：2024-05-24 16:52
2010 年开始正式接触 Linux，入门发行版是 Ubuntu 10.10，后来过渡到 Ubunu 11.04， 这其中也尝试了很多其他主流的发行版。进入实验室之后，开始用 CentOS 5，然后是 CentOS 6，现在进化到 CentOS 7。
使用了四年的 Linux，前三年都是在瞎折腾，浪费了不少时间，也得到了不少经验与教训。 现在可能是真的老了，已经不愿意折腾了，只希望配置好一个系统之后，就一直使用下去。
为什么要写/读这一篇
使用 Linux 尤其是 CentOS 会遇到一些坑，或是一些有洁癖的人不能忍的事情：
官方源中的软件包版本太老，在功能上无法满足需求； 多个源的软件包存在版本冲突； 手动编译软件，默认会将不同文件放置在/usr/local下不同的子目录下，使得软件的更新和删除变得麻烦。 等等
在经历了几次重装 CentOS 之后，特总结出如下几条软件安装的方法与原则，以尽可能保证当前系统的稳定、整洁，尽可能降低系统洁癖引起的重装冲动。
以下所说，仅限于 CentOS7，对其他发行版，或许有借鉴意义。
官方源
CentOS 自带的四个官方源中，默认打开的有 base、updates、extras，这三个源中包含了约 9000 个软件包，是最稳定、也是最值得信赖的源。
因而若一个软件包在官方源内，则应通过官方源安装:
sudo yum install PackageName
第三方源
官方源虽然包含了很多软件包，但无法满足日常需求。幸好有第三方源，可以作为官方源的补充。
在使用第三方源的过程中，最怕遇到这两个问题：
第三方源和官方源中有相同的包，导致官方源的包被第三方源替代； 多个第三方源中存在同一个软件包，且版本不一致，存在冲突；
这两个问题经常是致命的，出现各种预料不到的后果，因而选择第三方源要遵循如下原则：
只选择可靠的第三方源，要确保第三方源不会替换官方源中的包； 使用尽量少的第三方源，以保证第三方源之间不会冲突；
就 CentOS 而言，根据以上的原则，使用如下第三方源：
大型第三方源，已确认不会替换官方源的包，且相互之间无冲突 EPEL：包含 6500 多个软件，科研必备 ELRepo：包含几十个各种硬件的驱动程序 Nux Dextop：多媒体相关的软件包（与 EPEL 的个别软件相冲突，可忽略）
有些小型第三方源，仅包含了几个软件，确认与官方源和 EPEL 源不会冲突，也可以添加 Google Chrome：包含了 Google Chrome，不会与官方源和 EPEL 源冲突； Adobe：仅包含 flash 插件，已确认不会冲突； 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写的软件。这类软件没有给源代码，而是给了可以在当前平台下直接执行的二进制文件。大多数非开源的商业软件都采取这种办法。
比如 sublime_text、pycharm、mendeley、TauP、sac 等，直接解压，然后将解压后的文件夹复制到/opt目录下，然后将该软件的 bin 目录加入到 PATH 中即可。 比如 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 外的其他第三方软件源，进而可能导致包冲突。所以对该源的使用，要保持谨慎。
总结
简单总结一下:
为系统添加 EPEL 源、Nux Dextop、ELRepo 源和个别其他小型第三方源 能够从源中安装的就从源中安装 不能从源中安装的尽量找 rpm 包安装 找不到 rpm 包的就试试 linuxbrew 能不手动编译的就不要手动编译
热心网友
时间：2024-05-24 16:52
2010 年开始正式接触 Linux，入门发行版是 Ubuntu 10.10，后来过渡到 Ubunu 11.04， 这其中也尝试了很多其他主流的发行版。进入实验室之后，开始用 CentOS 5，然后是 CentOS 6，现在进化到 CentOS 7。
使用了四年的 Linux，前三年都是在瞎折腾，浪费了不少时间，也得到了不少经验与教训。 现在可能是真的老了，已经不愿意折腾了，只希望配置好一个系统之后，就一直使用下去。
为什么要写/读这一篇
使用 Linux 尤其是 CentOS 会遇到一些坑，或是一些有洁癖的人不能忍的事情：
官方源中的软件包版本太老，在功能上无法满足需求； 多个源的软件包存在版本冲突； 手动编译软件，默认会将不同文件放置在/usr/local下不同的子目录下，使得软件的更新和删除变得麻烦。 等等
在经历了几次重装 CentOS 之后，特总结出如下几条软件安装的方法与原则，以尽可能保证当前系统的稳定、整洁，尽可能降低系统洁癖引起的重装冲动。
以下所说，仅限于 CentOS7，对其他发行版，或许有借鉴意义。
官方源
CentOS 自带的四个官方源中，默认打开的有 base、updates、extras，这三个源中包含了约 9000 个软件包，是最稳定、也是最值得信赖的源。
因而若一个软件包在官方源内，则应通过官方源安装:
sudo yum install PackageName
第三方源
官方源虽然包含了很多软件包，但无法满足日常需求。幸好有第三方源，可以作为官方源的补充。
在使用第三方源的过程中，最怕遇到这两个问题：
第三方源和官方源中有相同的包，导致官方源的包被第三方源替代； 多个第三方源中存在同一个软件包，且版本不一致，存在冲突；
这两个问题经常是致命的，出现各种预料不到的后果，因而选择第三方源要遵循如下原则：
只选择可靠的第三方源，要确保第三方源不会替换官方源中的包； 使用尽量少的第三方源，以保证第三方源之间不会冲突；
就 CentOS 而言，根据以上的原则，使用如下第三方源：
大型第三方源，已确认不会替换官方源的包，且相互之间无冲突 EPEL：包含 6500 多个软件，科研必备 ELRepo：包含几十个各种硬件的驱动程序 Nux Dextop：多媒体相关的软件包（与 EPEL 的个别软件相冲突，可忽略）
有些小型第三方源，仅包含了几个软件，确认与官方源和 EPEL 源不会冲突，也可以添加 Google Chrome：包含了 Google Chrome，不会与官方源和 EPEL 源冲突； Adobe：仅包含 flash 插件，已确认不会冲突； 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写的软件。这类软件没有给源代码，而是给了可以在当前平台下直接执行的二进制文件。大多数非开源的商业软件都采取这种办法。
比如 sublime_text、pycharm、mendeley、TauP、sac 等，直接解压，然后将解压后的文件夹复制到/opt目录下，然后将该软件的 bin 目录加入到 PATH 中即可。 比如 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 外的其他第三方软件源，进而可能导致包冲突。所以对该源的使用，要保持谨慎。
总结
简单总结一下:
为系统添加 EPEL 源、Nux Dextop、ELRepo 源和个别其他小型第三方源 能够从源中安装的就从源中安装 不能从源中安装的尽量找 rpm 包安装 找不到 rpm 包的就试试 linuxbrew 能不手动编译的就不要手动编译
热心网友
时间：2024-05-24 16:52
2010 年开始正式接触 Linux，入门发行版是 Ubuntu 10.10，后来过渡到 Ubunu 11.04， 这其中也尝试了很多其他主流的发行版。进入实验室之后，开始用 CentOS 5，然后是 CentOS 6，现在进化到 CentOS 7。
使用了四年的 Linux，前三年都是在瞎折腾，浪费了不少时间，也得到了不少经验与教训。 现在可能是真的老了，已经不愿意折腾了，只希望配置好一个系统之后，就一直使用下去。
为什么要写/读这一篇
使用 Linux 尤其是 CentOS 会遇到一些坑，或是一些有洁癖的人不能忍的事情：
官方源中的软件包版本太老，在功能上无法满足需求； 多个源的软件包存在版本冲突； 手动编译软件，默认会将不同文件放置在/usr/local下不同的子目录下，使得软件的更新和删除变得麻烦。 等等
在经历了几次重装 CentOS 之后，特总结出如下几条软件安装的方法与原则，以尽可能保证当前系统的稳定、整洁，尽可能降低系统洁癖引起的重装冲动。
以下所说，仅限于 CentOS7，对其他发行版，或许有借鉴意义。
官方源
CentOS 自带的四个官方源中，默认打开的有 base、updates、extras，这三个源中包含了约 9000 个软件包，是最稳定、也是最值得信赖的源。
因而若一个软件包在官方源内，则应通过官方源安装:
sudo yum install PackageName
第三方源
官方源虽然包含了很多软件包，但无法满足日常需求。幸好有第三方源，可以作为官方源的补充。
在使用第三方源的过程中，最怕遇到这两个问题：
第三方源和官方源中有相同的包，导致官方源的包被第三方源替代； 多个第三方源中存在同一个软件包，且版本不一致，存在冲突；
这两个问题经常是致命的，出现各种预料不到的后果，因而选择第三方源要遵循如下原则：
只选择可靠的第三方源，要确保第三方源不会替换官方源中的包； 使用尽量少的第三方源，以保证第三方源之间不会冲突；
就 CentOS 而言，根据以上的原则，使用如下第三方源：
大型第三方源，已确认不会替换官方源的包，且相互之间无冲突 EPEL：包含 6500 多个软件，科研必备 ELRepo：包含几十个各种硬件的驱动程序 Nux Dextop：多媒体相关的软件包（与 EPEL 的个别软件相冲突，可忽略）
有些小型第三方源，仅包含了几个软件，确认与官方源和 EPEL 源不会冲突，也可以添加 Google Chrome：包含了 Google Chrome，不会与官方源和 EPEL 源冲突； Adobe：仅包含 flash 插件，已确认不会冲突； 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写的软件。这类软件没有给源代码，而是给了可以在当前平台下直接执行的二进制文件。大多数非开源的商业软件都采取这种办法。
比如 sublime_text、pycharm、mendeley、TauP、sac 等，直接解压，然后将解压后的文件夹复制到/opt目录下，然后将该软件的 bin 目录加入到 PATH 中即可。 比如 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 外的其他第三方软件源，进而可能导致包冲突。所以对该源的使用，要保持谨慎。
总结
简单总结一下:
为系统添加 EPEL 源、Nux Dextop、ELRepo 源和个别其他小型第三方源 能够从源中安装的就从源中安装 不能从源中安装的尽量找 rpm 包安装 找不到 rpm 包的就试试 linuxbrew 能不手动编译的就不要手动编译
热心网友
时间：2024-05-24 16:52
2010 年开始正式接触 Linux，入门发行版是 Ubuntu 10.10，后来过渡到 Ubunu 11.04， 这其中也尝试了很多其他主流的发行版。进入实验室之后，开始用 CentOS 5，然后是 CentOS 6，现在进化到 CentOS 7。
使用了四年的 Linux，前三年都是在瞎折腾，浪费了不少时间，也得到了不少经验与教训。 现在可能是真的老了，已经不愿意折腾了，只希望配置好一个系统之后，就一直使用下去。
为什么要写/读这一篇
使用 Linux 尤其是 CentOS 会遇到一些坑，或是一些有洁癖的人不能忍的事情：
官方源中的软件包版本太老，在功能上无法满足需求； 多个源的软件包存在版本冲突； 手动编译软件，默认会将不同文件放置在/usr/local下不同的子目录下，使得软件的更新和删除变得麻烦。 等等
在经历了几次重装 CentOS 之后，特总结出如下几条软件安装的方法与原则，以尽可能保证当前系统的稳定、整洁，尽可能降低系统洁癖引起的重装冲动。
以下所说，仅限于 CentOS7，对其他发行版，或许有借鉴意义。
官方源
CentOS 自带的四个官方源中，默认打开的有 base、updates、extras，这三个源中包含了约 9000 个软件包，是最稳定、也是最值得信赖的源。
因而若一个软件包在官方源内，则应通过官方源安装:
sudo yum install PackageName
第三方源
官方源虽然包含了很多软件包，但无法满足日常需求。幸好有第三方源，可以作为官方源的补充。
在使用第三方源的过程中，最怕遇到这两个问题：
第三方源和官方源中有相同的包，导致官方源的包被第三方源替代； 多个第三方源中存在同一个软件包，且版本不一致，存在冲突；
这两个问题经常是致命的，出现各种预料不到的后果，因而选择第三方源要遵循如下原则：
只选择可靠的第三方源，要确保第三方源不会替换官方源中的包； 使用尽量少的第三方源，以保证第三方源之间不会冲突；
就 CentOS 而言，根据以上的原则，使用如下第三方源：
大型第三方源，已确认不会替换官方源的包，且相互之间无冲突 EPEL：包含 6500 多个软件，科研必备 ELRepo：包含几十个各种硬件的驱动程序 Nux Dextop：多媒体相关的软件包（与 EPEL 的个别软件相冲突，可忽略）
有些小型第三方源，仅包含了几个软件，确认与官方源和 EPEL 源不会冲突，也可以添加 Google Chrome：包含了 Google Chrome，不会与官方源和 EPEL 源冲突； Adobe：仅包含 flash 插件，已确认不会冲突； 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写的软件。这类软件没有给源代码，而是给了可以在当前平台下直接执行的二进制文件。大多数非开源的商业软件都采取这种办法。
比如 sublime_text、pycharm、mendeley、TauP、sac 等，直接解压，然后将解压后的文件夹复制到/opt目录下，然后将该软件的 bin 目录加入到 PATH 中即可。 比如 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 外的其他第三方软件源，进而可能导致包冲突。所以对该源的使用，要保持谨慎。
总结
简单总结一下:
为系统添加 EPEL 源、Nux Dextop、ELRepo 源和个别其他小型第三方源 能够从源中安装的就从源中安装 不能从源中安装的尽量找 rpm 包安装 找不到 rpm 包的就试试 linuxbrew 能不手动编译的就不要手动编译
