Software installation methods and strategies under CentOS 7

Some crap

Since 2010, when the formal contact with Linux began, the starter release was Ubuntu 10.10, which later transitioned to Ubunu 11.04, which also tried a number of other mainstream distributions. After entering the lab, we started with CentOS 5 and then CentOS 6, now evolving to CentOS 7.

Using four years of Linux, the first three years are in the blind toss, wasted a lot of time, also got a lot of experience and lessons. Now may be really old, have been reluctant to toss, only want to configure the good one system, has been used down.

Why write/Read this article

Using Linux in particular, CentOS will encounter some pits, or some people who are neat and tidy can not tolerate things:

1. The version of the package in the official source is too old to meet the requirements in a functional way;
2. A version conflict exists for multiple source packages;
3. Manually compiling software, by default, will place different files under different subdirectories under /usr/local , making it cumbersome to update and delete software.
4. Wait a minute...

After several re-install CentOS, the following software installation methods and principles, to ensure that the current system stability, cleanliness, as far as possible to reduce the system cleanliness caused by the reload impulse.

As mentioned below, limited to CentOS7, may be useful for other distributions.

Official source

Of the four official sources from CentOS, the default is the base, updates, and extras, which contain about 9,000 packages, and are the most stable and trustworthy source in the three sources.

Thus, if a package is in the official source, it should be installed through the official source:

sudo yum install PackageName

Third-party sources

Although the official source contains many packages, it does not meet the daily requirements. Fortunately there are third-party sources that can be supplemented as official sources.

In the process of using third-party sources, you are most afraid of encountering these two problems:

1. Third-party sources and official sources of the same package, resulting in the official source of the package is replaced by the third FountainVest partners;
2. Multiple third-party sources exist in the same package, and the version is inconsistent, there is a conflict;

These two issues are often fatal and have unexpected consequences, so choosing a third-party source follows the following principles:

1. Select only reliable third-party sources to ensure that third-party sources do not replace packages from official sources;
2. Use as few third-party sources as possible to ensure that there are no conflicts between third-party sources;

In the case of CentOS, the following third-party sources are used in accordance with the above principles:

1. Large third-party source, confirmed not to replace the official source of the package, and no conflict with each other
   1. EPEL: Contains more than 6,500 software, scientific research must
   2. ELRepo: Dozens of drivers with a variety of hardware
2. Some small third-party sources, which contain only a few software, confirm that there is no conflict with the official source and Epel sources, or you can add
   1. Google Chrome: Google Chrome does not conflict with official sources and epel sources;
   2. Adobe: contains only flash plug-ins, confirmed that there will be no conflict;
   3. Dropbox: Contains only one Dropbox software and has been confirmed not to conflict;

Thus, if a package is in Epel, Elrepo, or some small third-party source, add the third-party source and install it with the Yum command:

sudo yum install PackageName

Official RPM Package

Most of the non-open source software is not in the CentOS official source or Epel. Some of the software's official website will provide the official RPM package. At this point, you can download the RPM package corresponding to the current system from the official website and install it directly with the following command:

sudo rpm-i packagename.rpm

For example,WPS for Linux is one of them. The RPM command automatically checks for dependencies during installation, and installs automatically if the packages on which the software depends are found in the official source and Epel sources.

It's easy to install the RPM package directly, but the software can't be updated by Yum, which is a little bit cumbersome. Some software, such as the aforementioned Google, Dropbox, and Adobe can also be installed in this way, while the installation will add source to the system, for such software is still easy to update and delete.

Unzip ready to use

Some software, the official supply of compressed package, decompression can directly run the binary files, such as many Java written software. This kind of software does not give the source code, but instead gives the binary files that can be executed directly under the current platform. Most of the non-open source business software is taking this approach.

1. For example, Sublime_text, Pycharm, Mendeley, Taup, SAC, etc., directly decompression, and then copy the extracted folder to the /opt directory, and then add the software's Bin directory to the path.
2. such as mathematics, Matlab, Intel Studio, the package provides the installation script, execute the script can be installed;

The custom under Linux is that commercial software or third-party software is installed in the /opt directory, which is the default installation path for most business packages, and is as much as possible.

Third-party RPM packages

Some software, CentOS source and Epel source can not be found, the official does not provide RPM package, but other third-party sources provide RPM package. Sub-situation discussion:

• If the third-party source contains only a small number of packages and determines that they do not conflict with the official source and other used third-party sources, you can add the third-party source.
• If the third-party source contains a lot of software and is likely to conflict with an official source or Epel source, do not add the source
  • If the package does not have a complex dependency, install the RPM package in the source directly;
  • If the package relies on other packages in the third-party source, discard and look for other methods;

Third-party Package Manager

Different distributions use different package managers, and CentOS uses Yum,ubuntu to use Apt-get. In recent years, there have been some third-party package managers unrelated to the distribution, such as Linuxbrew, Gentoo Prefix, and pkgsrc.

Linuxbrew

Linuxbrew is ported to Linux under the very popular homebrew OS X platform. Linuxbrew can be added as a complement to the package manager that comes with the system. It features:

• All software is installed under the ${home}/.linuxbrew directory;
• The version of the software is relatively new;
• Install, uninstall, info, list, update, upgrade and other functions
• If you don't have a package in your library, you can easily create your own formulae

A trial, a comparative pit of the place is, Linuxbrew will own internal solution to the dependency problem. For example, I tried to install Terminator through Linuxbrew and then found that terminator depended on Python, even though the system already had python,linuxbrew installed and would install a python, and because Python relies on more things , resulting in the installation of more packages under home. Moreover, Linuxbrew is compiled from the source code, so the relative speed is relatively slow.

Compiling source code

Most of the software should be able to be installed in front of several methods. If it is not installed, then you have to ask yourself, really need to install this software. If it's not very necessary, don't install it. If the software is necessary, it must be compiled manually.

Common source code compilation, generally is the following steps. Of course, the specific situation is specifically treated:

TAR-XVF xxxx.tgz./configure--prefix=/opt/xxxxmakesudo make install

In general, the default installation directory for such software is /usr/local, and the final file will be placed in the /usr/local bin, lib, share, and man directories respectively.

I personally do not like this way, because as a source compiled by the software, it means that the compiler to fully take the responsibility to manage the software, such placement will be to update or uninstall the software caused a lot of trouble. So I always add prefix to configure. Manually specify the installation path. To uninstall the software directly delete the corresponding directory under/OPT, to update, you can also delete, and then recompile again. The trouble with this is that you need to manually add the bin directory of the software to PATH, and you may need to modify the Ld_library_path. But in general, the need to compile the source of software is very few, so it will not cause too much trouble.

Compiling code

Well, actually I don't know how to start the title.

The previous section, "compiling the source code" is mainly for some large software packages, this section of "compiled codes" refers to some of the professional very strong small code package processing way. For example, some packages actually need a binary file after compiling, this time there is no need to install to /opt , the appropriate way is to build the bin directory under their own home, and add its path to the . BASHRC , Then copy the compiled binaries to the directory:

mkdir ${home}/binecho ' export path=${home}/bin: $PATH ' >> ~/.BASHRC

For example, my ${home}/bin directory has the following files:

• Distaz: gives the latitude and longitude of two points on the Earth, calculates the epicenter distance and the azimuth angle
• Pssac: Draw sac File in GMT
• rdseed: Seed format Transfer SAC format
• win2sac_32,catwin32: Programs provided by the Hi-net website for processing hi-net data
• St: Sublime_text is installed in the /opt directory, where a soft link is created to facilitate invoking sublime text on the command line
• wlt.pl: A script used to log in to the network through the school, modify the network port on the command line, good happy
• FK,fk.pl,syn,Trav: Prof. Lupei Zhu for the calculation of synthetic seismic map of the program, there are a lot of source code, the actual need to use the three executable files and a Perl script.
• matlab: A soft connection pointing to Matlab;

Do not put any binary files into the bin, here should only put some common commands or very common tools.

Self-made system software

There is a kind of software, which has many modules or packages, in order to manage the numerous modules, it is necessary to have a own module/Package Manager. This is represented by Tex, Perl, and Python. For this kind of software, its many modules are the biggest advantage, is also the most worth of resources, so I usually choose to manually install them for the following reasons:

• All modules of the software may not be included in the source of the system;
• The system source of the software module update is far behind the latest version;

Of course, even with the system's own version, you can still use the package manager that comes with the software to install the module. But will cause:

• Part of the module with the system of Yum management, some modules with the software comes with the Package Manager management;
• Yum installs the general version of the module is older, the software package Manager to install most of the latest version;

This can lead to confusion in the management of the module, on the other hand, the software comes with a package to manage its installation module, may rely on the latest version of other modules, if the module is installed through the system Yum older version, it may cause the module installation failure.

Therefore, for this kind of software, generally installed separately, and the respective Package Manager management module:

• Texlive: Install with texlive ISO image file with its own Tlmgr Management Pack
• Perl: Install the latest version of Perl via Plenv, using the CPANM installation module plenv comes with
• Python: Install the latest version of Python via pyenv, using the PIP installation module from Python

Exception

There are always exceptions to rules.

Third-party sources

Mosquito-myrepo is a private maintenance source, which contains Chinese input method,QQ, fetion, for notes, Youdao Dictionary, Baidu Cloud and a number of audio, video players. My attitude to this source is love and hate, it provides a lot of Chinese needs software, but because it relies on other than epel other third-party software sources, which may lead to packet conflict. So be cautious about the use of the source.

Summarize

Briefly summarize:

1. Add Epel source, Elrepo source, and individual other small third-party sources to the system
2. The ability to install from the source is installed from the source
3. Cannot install from source to try to find RPM package installation
4. If you can't find the RPM package, try Linuxbrew.
5. Do not compile manually without compiling manually

Revision history

1. 2014-11-23: First draft;
2. 2014-12-01: Add Elrepo Source to third party source;

So what does you think? Did I miss something? Is any part unclear? Leave your comments below.

Software installation methods and strategies under CentOS 7