Full analysis of CentOS7 software installation steps and strategies

I started to officially come into contact with Linux in 2010. The entry-level distribution was Ubuntu 10.10, and later transitioned to Ubunu 11.04. During this period, I also tried many other mainstream distributions. After entering the lab, I started using CentOS 5, then CentOS 6, and now evolved to CentOS 7.

I have been using Linux for four years. The first three years were spent messing around, wasting a lot of time, and gaining a lot of experience and lessons. Maybe I am really old now and am no longer willing to bother with it. I just hope that after configuring a system, I can continue to use it.

Why should I write/read this article

When using Linux, especially CentOS, you will encounter some pitfalls, or some things that people with mysophobia cannot tolerate:

The software package version in the official source is too old and cannot meet the functional requirements; software packages from multiple sources have version conflicts; manually compiling the software will place different files in different subdirectories under /usr/local by default , making software updates and deletions troublesome. etc…

After reinstalling CentOS several times, I have summarized the following software installation methods and principles to ensure the stability and cleanliness of the current system as much as possible, and to reduce the urge to reinstall caused by system hysteria as much as possible.

The following is limited to CentOS7, and may be of reference to other distributions.

Official source

Among the four official sources that come with CentOS, base, updates, and extras are opened by default. These three sources contain about 9,000 software packages and are the most stable and trustworthy sources.

So if a software package is in the official source, it should be installed from the official source:

sudo yum install PackageName

Third Party Source

Although the official source contains many software packages, it cannot meet daily needs. Fortunately, there are third-party sources that can supplement the official sources.

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

There are the same packages in third-party sources and official sources, causing the official source packages to be replaced by third-party sources; the same software package exists in multiple third-party sources, and the versions are inconsistent and there is a conflict;

These two problems are often fatal and have various unexpected consequences. Therefore, when choosing a third-party source, you must follow the following principles:

Only choose reliable third-party sources, and make sure that the third-party sources will not replace the packages in the official sources; use as few third-party sources as possible to ensure that there will be no conflicts between third-party sources;

As far as CentOS is concerned, according to

Large third-party source, it has been confirmed that it will not replace the official source package, and there is no conflict with each other. EPEL: contains more than 6500 software, essential for scientific research ELRepo: contains dozens of drivers for various hardware Nux Dextop: Multimedia related software packages (conflicts with individual EPEL software and can be ignored)

Some small third-party sources only include a few software, confirm that they will not conflict with the official sources and EPEL sources, you can also add Google Chrome: Google Chrome is included, and will not conflict with the official sources and EPEL sources; Adobe: It only contains the flash plug-in, and it has been confirmed that there will be no conflict; dropbox: it only contains the dropbox software, and it has been confirmed that there will be no conflict;

Therefore, if a software package is located in EPEL, ELRepo, or some small third-party sources, add the third-party source and install it with the yum command:

sudo yum install PackageName

Official rpm package

Most non-open source software is not available in CentOS official sources or EPEL. The official website of some software will provide official rpm packages. At this time, 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. During the installation process, the rpm command will automatically check dependencies. If the packages that the software depends on can be found in the official source and EPEL source, they will be installed automatically.

It is quite easy to install the rpm package directly, but the software cannot be updated by yum, which is a little troublesome. Some software, such as the aforementioned Google, Dropbox and Adobe, can actually be installed through this method. Sources will be added to the system during installation, and such software can still be easily updated and deleted.

Unzip and use

For some software, the official provides compressed packages. After decompression, you can directly run the binary files in them, such as many software written in Java. This type of software does not provide source code, but binary files that can be executed directly under the current platform. Most non-open source commercial software takes this approach.

For example, sublime_text, pycharm, mendeley, TauP, sac, etc., decompress directly, then copy the decompressed folder to the /opt directory, and then add the bin directory of the software to PATH. For example, Mathematics, Matlab, and intel studio, the installation script is provided in the software package, and you can install it by executing the script;

The habit under Linux is that commercial software or third-party software are installed in the /opt directory. This is also the default installation path for most commercial software packages. Try to follow this habit.

Third party rpm package

Some software cannot be found in the CentOS source and EPEL source. The official rpm package is not provided, but other third-party sources provide rpm packages. Discuss on a case-by-case basis:

If the third-party source only contains a small number of packages, and it is determined that these packages 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 the official source or EPEL source, the source will not be added. If the software package does not have complex dependencies, install the rpm package in the source directly; if the software package If you depend on other packages in the third-party source, give up and look for other methods;

Third Party Package Manager

Different distributions use different package managers, CentOS uses yum, and Ubuntu uses apt-get. In recent years, some distribution-independent third-party package managers have appeared, such as Linuxbrew, Gentoo Prefix, and pkgsrc.

Linuxbrew

Linuxbrew is ported to Linux from the very popular Homebrew under the OS X platform. Linuxbrew can be used as a supplement to the package manager that comes with the system. Its characteristics are:

All software is installed in the ${HOME}/.linuxbrew directory; the version of the software is relatively new; functions such as install, uninstall, info, list, update, upgrade, etc. can be very simple if there are no required software packages in the library. Create your own formulae

After trying it out, one of the pitfalls is that linuxbrew will solve the dependency problem internally. For example, I tried to install terminator through linuxbrew, and then found that terminator depends on Python. Although python is already installed on the system, linuxbrew will still install a copy of python, and because python depends on more things, more software packages are installed. Under home. Moreover, linuxbrew compiles software from source code, so it is relatively slow.

Compile source code

Most software should be able to be installed using the previous methods. If it is not installed, then you have to ask yourself whether you really need to install this software. If it is not absolutely necessary, do not install it. If it is necessary software, it must be compiled manually.

Common source code compilation generally involves the following steps. Of course, specific situations will be treated on a case-by-case basis:

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

Generally speaking, the default installation directory of this type of software is /usr/local, and the final files will be placed in the bin, lib, share, and man directories of /usr/local.

I personally don’t like this method very much, because as a software compiled from source code, it means that the compiler must fully bear the obligation to manage the software. This placement method will cause a lot of problems when updating or uninstalling the software. trouble. So I always add prefix to manually specify the installation path when configuring. To uninstall the software, just delete the corresponding directory under /opt. If you want to update, you can also delete it first and then recompile it. The slightly troublesome thing about doing this is that you need to manually add the bin directory of the software to PATH, and you may also need to modify LD_LIBRARY_PATH. But generally speaking, there are very few software that require compilation of source code, so it won't cause much trouble.

Compile code

Okay, actually I don’t know how to title it. .

The previous section "Compiling source code" mainly focuses on some large software packages. This section "Compiling code" refers to the processing method of some highly professional small code packages. For example, after some software packages are compiled, all they actually need is a binary file. At this time, there is no need to install it in /opt. The appropriate way is to create a bin directory under your own HOME, add its path to .bashrc, and then add Just copy the compiled binary file to this directory:

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

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

distaz: Given the longitude and latitude of two points on the earth, calculate the epicentral distance and azimuth angle pssac: Draw the SAC file in GMT rdseed: Convert SEED format to SAC format win2sac_32, catwin32: Provided by the Hi-net website for processing Hi-net The data program st: sublime_text is installed in the /opt directory, and a soft link is established here to facilitate calling sublime text on the command line. wlt.pl: the school's script for logging into the Internet, modify the network port on the command line, so happy fk, fk.pl, syn, trav: Prof. Lupei Zhu’s program for calculating synthetic seismograms. There are many source codes. In fact, these three executable files and a perl script are all that are needed. matlab: a soft connection pointing to matlab;

Don’t put any binary files into bin. Only some commonly used commands or very common tools should be put here.

Self-contained system software

There is a type of software that has many modules or packages. In order to manage these many modules, you need to have your own module/package manager. Among them are TeX, Perl and Python. For this type of software, its numerous modules are the biggest advantage and the most worthwhile resource, so I usually choose to install them manually for the following reasons:

It is impossible for the system source to contain all modules of the software; the update of the software modules in the system source lags far behind the latest version;

Of course, even if you use the version that comes with the system, you can still use the package manager that comes with the software to install the module. But will result in:

Some modules are managed by the system's yum, and some modules are managed by the package manager that comes with the software; the modules installed by yum are generally older versions, and the software's package manager needs to install mostly the latest version;

On the one hand, this will lead to confusion in module management. On the other hand, when using the package that comes with the software to manage its installed modules, it may rely on the latest versions of other modules. If the module is older installed through the system yum version, it may cause the module installation to fail.

Therefore, for this type of software, it is generally installed separately and uses its own package manager to manage the modules:

TeXLive: Install through the TeXLive iso image file, use its own tlmgr management package Perl: Install the latest version of Perl through plenv, use the cpanm that comes with plenv to install the module Python: Install the latest version of Python through pyenv, use Python Comes with pip installation module

Exceptions

There are always exceptions to rules.

Third Party Source

mosquito-myrepo is a privately maintained source, which includes Chinese input method, QQ, Fetion, Weizhi Notes, Youdao Dictionary, Baidu Cloud and several audio and video players. I have a love-hate attitude towards this source. It provides a lot of software that Chinese people need, but because it relies on third-party software sources other than EPEL, it may cause package conflicts. So use this source with caution.

Summarize

A brief summary:

Add EPEL source, Nux Dextop, ELRepo source and some other small third-party sources to the system. If you can install it from the source, install it from the source. If you cannot install it from the source, try to find the rpm package. If you cannot find the rpm package, just install it. Try linuxbrew. If you can compile it manually, don’t compile it manually

The above is the detailed content of Full analysis of CentOS7 software installation steps and strategies. For more information, please follow other related articles on the PHP Chinese website!