Shulou(Shulou.com)06/01 Report--

This article mainly shows you the "sample analysis of software installation methods and strategies in CentOS7", which is easy to understand and well-organized. I hope it can help you solve your doubts. Let me lead you to study and learn "sample analysis of software installation methods and strategies in CentOS7".

Starting with Linux in 2010, the entry-level release was Ubuntu 10.10, and then transitioned to Ubunu 11.04, which also tried many other mainstream distributions. After entering the lab, he started using CentOS 5, then CentOS 6, and now evolved to CentOS 7.

Linux, which has been used for four years, has been messing around in the first three years, wasting a lot of time and getting a lot of experience and lessons. Now may be really old, do not want to toss around, just hope that after the configuration of a system, it will continue to use.

Why write / read this article?

When using Linux, especially CentOS, you will encounter some pitfalls, or things that cleanliness addicts can't stand:

The version of the software package in the official source is too old to meet the requirements in function; there are version conflicts in the software packages of multiple sources; manually compiling the software will place different files in different subdirectories under / usr/local by default, which makes it troublesome to update and delete the software. Wait...

After several times of reinstalling CentOS, the following software installation methods and principles are summarized in order to ensure the stability and cleanliness of the current system and reduce the reinstallation impulse caused by system cleanliness as much as possible.

The following is limited to CentOS7 and may be useful for other distributions.

Official source

Of the four official sources that come with CentOS, base, updates, and extras are opened by default. These three sources contain about 9000 software packages, which are the most stable and trusted sources.

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

Sudo yum install PackageName

Third party source

Although the official source contains many software packages, it can not meet the daily needs. Fortunately, there is a third source, which can be used as a supplement to the official source.

In the process of using third-party sources, I am most afraid to encounter these two problems:

There is the same package in the third party source and the official source, which causes the package of the official source to be replaced by the third party source. The same software package exists in multiple third party sources, and the version is inconsistent, resulting in conflicts.

These two problems are often fatal, with a variety of unintended consequences, so the selection of third-party sources should follow the following principles:

Choose only reliable third-party sources and ensure that third-party sources do not replace packets in official sources; use as few third-party sources as possible to ensure that there are no conflicts between third-party sources

In the case of CentOS, according to the above principles, use the following third-party sources:

Large third-party source, it has been confirmed that the official source package will not be replaced, and there is no conflict between EPEL: contains more than 6500 pieces of software, scientific research essential ELRepo: contains dozens of various hardware drivers Nux Dextop: multimedia-related software packages (conflicts with individual software of EPEL, negligible)

Some small third-party sources contain only a few softwares to confirm that they will not conflict with official sources and EPEL sources. You can also add Google Chrome: contains Google Chrome and will not conflict with official sources and EPEL sources; Adobe: contains only flash plug-ins and has confirmed that there will be no conflicts; dropbox: contains only dropbox software and has been confirmed that there will be no conflicts

Therefore, 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 non-open source software is not available in CentOS official sources or EPEL. The official rpm package is available on the official website of some software. 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

The rpm command automatically checks for dependencies during installation, and installs automatically if the package on which the software depends can be found in the official and EPEL sources.

It is quite easy to install the rpm package directly, but the software cannot be updated by yum, which is a little more troublesome. Some software, such as Google, Dropbox and Adobe mentioned earlier, can also be installed in this way, adding sources to the system during installation, and this kind of software can still be easily updated and deleted.

Decompression is ready for use

For some software, the official compression package can be unzipped and run the binaries directly, such as many software written by Java. This type of software is not given source code, but rather binaries that can be executed directly on the current platform. Most non-open source commercial software takes this approach.

For example, sublime_text, pycharm, mendeley, TauP, sac, etc., extract directly, then copy the extracted folder to the / opt directory, and then add the bin directory of the software to PATH. For example, Mathematics, Matlab, intel studio, the installation script is provided in the package, which can be installed by executing the script.

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

Third-party rpm package

Some software can not be found in CentOS and EPEL sources, and rpm packages are not officially available, but rpm packages are available from other third-party sources. Discuss on a case-by-case basis:

If the third-party source contains only 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, do not add the source. If the package does not have complex dependencies, install the rpm package in the source directly; if the package depends on other packages in the third-party source, abandon it and look for other ways

Third-party package manager

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

Linuxbrew

Linuxbrew is ported to Linux by Homebrew, which is very popular on the OS X platform. Linuxbrew can be used as a supplement to the package manager that comes with the system. Its features are as follows:

All the software is installed in the ${HOME} / .linuxbrew directory; the version of the software is relatively new; if the functions such as install, uninstall, info, list, update, upgrade, etc., do not have the required software packages in the library, you can easily create your own formulae

Try it out, and one of the pitfalls is that linuxbrew will solve the dependency problem internally. For example, I tried to install terminator through linuxbrew and found that terminator depended on Python, and even though the system had already installed python,linuxbrew, it would install a copy of python, and because python depended on more things, more packages were installed under home. Moreover, linuxbrew compiles the software from source code, so it is relatively slow.

Compile source code

Most of the software should be able to be installed using the previous methods. If you don't install it, you have to ask yourself if you really need to install this software. Do not install it if it is not necessary. If it is a necessary software, it must be compiled manually.

The common source code compilation is usually the following steps.

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

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

Personally, I don't like this approach very much, because as a software compiled by source code, it means that the compiler has to take full responsibility for managing the software, which can cause a lot of trouble to update or uninstall the software. So I always add prefix to configure to specify the installation path manually. To uninstall the software, delete the corresponding directory under / opt directly, or delete it first and compile it again if you want to update it. The slight hassle of doing this is that you need to manually add the software's bin directory to the PATH, and you may need to modify the LD_LIBRARY_PATH. But generally speaking, there is very little software that needs to compile the source code, so it won't cause too much trouble.

Compiled code

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

The previous section "compiling source code" is mainly aimed at some large software packages, and this section "compiling code" refers to the handling of some professional small code packages. For example, some software packages actually need only a binary file after compilation, so it is not necessary to install to / opt at this time. The appropriate way is to create a bin directory under your own HOME, add its path to .bashrc, and then copy the compiled binaries to this directory:

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

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

Distaz: give two points of longitude and latitude on the earth, calculate epicenter distance and azimuth pssac: draw SAC files in GMT rdseed: SEED format to SAC format win2sac_32, catwin32: Hi-net website provides a program for processing Hi-net data st: sublime_text is installed in the / opt directory, set up a soft link here to facilitate the command line to call sublime text wlt.pl: school script for logging into the network, and modify the network port on the command line Good happy fk, fk.pl, syn, trav: Prof. Lupei Zhu program for calculating synthetic seismograms, there are a lot of source code, the actual need is only these three executable files and a perl script. Matlab: a soft connection to matlab

Don't put any binaries in bin, just some commonly used commands or very general tools.

Self-contained software

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

The source of the system cannot contain all the modules of the software; the update of the module of the software in the source of the system 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 it will lead to:

Some modules are managed by the yum of the system, and some modules are managed by the package manager that comes with the software; the modules installed by yum are generally older, and most of the package managers of the software are installed with the latest version.

On the one hand, it will lead to confusion in module management, on the other hand, when managing its installation module with its own package, it may rely on the latest version of other modules. If the module is an older version installed through the system yum, it may cause the installation of the module to fail.

Therefore, for this type of software, it is generally installed separately and managed by their respective package managers:

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

Exception

There are rules, there are always exceptions.

Third party source

Mosquito-myrepo is a privately maintained source that includes Chinese input method, QQ, Fetion, Weizhi Notes, youdao Dictionary, Baidu Cloud and several audio and video players. My attitude towards this source is both love and hate, which provides a lot of software that Chinese people need, but because it relies on third-party software sources other than EPEL, it may lead to package conflicts. So be cautious about the use of this source.

The above is all the contents of the article "sample Analysis of Software installation methods and Strategies in CentOS7". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.