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

This article is about how to install software in Linux. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

In general, there are three main ways to install software under Linux:

One is source code installation, which requires users to compile manually.

The other is the RPM package (RedHat Linux Packet Manager), which can be installed through the RPM command

The other is the * .bin file, which is similar to the installation process under Windows

Generally speaking, Linux software is installed mainly in the following two ways

The ① file name is like xxx.i386.rpm, and the package is released in binary form.

② file name such as xxx.tar.gz, software packages are mostly released in the form of source code.

Linux package management can be divided into three categories: binary package management, source code package management, and script installation.

It is also worth noting that there are various Linux distributions that can obtain and install software in many ways, such as

[] yum installation of redhat/centos (with special mirror source)

[] Ubuntu/Fedora/Debian 's sudo apt-get is suitable for deb package management installation

[] some software is installed in the form of engraving encryption (e.g. cnyunwei)

[] in terms of system operation and maintenance personnel, there are also applications for automatic management through some software commands executed by ssh, Cripple + language or py, which will not be described in detail here.

Here is a diagram that clearly shows the architectural relationships of linux software applications:

When Linux starts. First the kernel (kernel) is started, which is a computer program that directly manages the hardware, including CPU, memory space, hard disk interface, network interface, and so on. All computer operations are passed to the hardware through the kernel. We can see that Linux uses kernel to realize the dialogue between software and hardware. Through this important interface of system call, Linux completely separates the upper application from the lower kernel, hiding the underlying complexity for the programmer (accordingly, it also improves the portability of the upper application). When we upgrade kernel, we can also keep the statement of the system call unchanged, so that the upper application does not feel the change of the lower layer. Library functions use system calls to create modular functionality, while shell provides a user interface and allows us to write scripts using shell syntax to integrate programs. With these ideas, we can quickly understand the installation and working principle of linux software applications, so in order to facilitate and obtain more enterprise applications, we need to develop on linux systems and make various software packages by source code compilation to serve the information age.

This paper mainly introduces the installation of source code and the installation of RPM package.

According to the actual situation of each company or author, source packages and commercial software packages can be compressed packages in tar format, source programs of bin, files that have been compiled and directly used to run, or other media such as CD-ROM virtual files to produce and release iso files, etc.) are packaged and released into a specific format to carry out corresponding software services. In fact, software installed through the yum or make install command will automatically generate rpm packages on the system (only parameters and functional modules are different and rigorous)

Brief introduction:

RPM (RedHat Package Manager, Red Hat package Manager) is used to install, query, upgrade, verify, uninstall, and generate the .rpm format software package RPM before use.

Install the installation CD of the linux system (centos4 as an example), and of course you can download the free RPM package online.

# mount/dev/cdrom-Mount the CD

# cd/media/cdrom/CentOS/RPMS-enter the directory of the RPM package on the CD (you can view the mount point of the CD by using the # mount command, which is usually displayed on the last line)

# ls

I. Source package installation

1. Source code package in the form of * .src.rpm

Usage:

Installation: rpm-rebuild * .src.rpm

Cd / usr/src/dist/RPMS

Rpm-ivh * .rpm

Uninstall: rpm-e packagename

2. Installation of .tar.gz, * .tgz,*.bz2 form software package

Decompress it first, and the command is as follows

Tar zxvf * .tar.gz

Tar xvfz * .tgz

Tar xvfj * .tar.bz2

After decompressing, go to the decompression directory, and then do the following (in general, depending on the file name of the package)

Configuration:. / configure

Compilation: make

Installation: make install

Uninstall: make uninstall

Source code installation is difficult, different software may have different installation, generally after decompression should first read the instructions, according to the instructions for installation, the above is only a general situation.

II. RPM package installation

RPM installation package format is proposed by Redhat company, which greatly simplifies the installation of software under Linux. First of all, introduce the general options.

-v: display additional information

-vv: displays debugging information

-- root directory: let RPM use directory as the root directory, so that both the pre-installer and the post-installer will be installed in this directory.

1. Install: rpm-I file.rpm

Options:

H: output hash tokens during installation

Test: only test the installation, not the actual installation

-- persent: displays the installation progress as a percentage

-- excludedocs: do not install the documentation in the package

-- replacepkgs: force reinstallation

-- replacefiles: replace files that belong to other software packages

-- force: ignore package and document conflicts

-- ignorearch: do not verify the structure of the software package

-- ignoreos: do not check the operating system on which the package is running

-- nodeps: do not check for dependency relationships

-- noscripts: do not run pre-installation and post-installation scripts

2. Delete rpm-e pkgname

Option:

-- test: only do deletion tests, not really delete

-- noscripts: do not run pre-installation and post-installation scripts

-- nodeps: do not check for dependencies

Note: pkgname is the name of the package, not the name of the rpm package, but the name of the installed package. You can use the query command to query the package name.

3. Upgrade rpm-U (or-upgrade) file.rpm

Option:

Basically the same as the option at installation, there are several special

-- oldpackage: allow an old version

4. Query rpm-Q (or-- query)

Option:

-p PACKAGE_FILE: query the files of the software package

-f FIEL: query which software package FILE belongs to

-a: query all installed software packages

-g group: query software packages that belong to the group group

-- whatproVidesCAPABILITY: query software packages that provide CAPABILITY functionality

-- whatrequiresCAPABILITY: query all software packages that require CAPABILITY functionality

-I: displays the summary information of the package

-l: displays a list of files in the package

-c: displays a list of profiles

-s: display a list of files

-scripts: displays installation, uninstallation, and verification scripts

-- qf: query in a user-specified way

-- dump: displays the check information for each file

-- proVides: displays the functions provided by the software package

-R: displays the features required by the package

5. Verify the installed software package rpm-V (or-verify,or-y)

The Option option is similar to that of other commands

6. Verify the file rpm-K (or-checksig) file.rpm in the verification package

Option:

-v: displays version information

-vv: displays debugging information

-- rcfile FILELIST: set the rpmrc file to FILELIST

7. Other RPM options

-- rebuilddb: rebuilding RPM database

-- initdb: create a new RPM database

-- quiet: minimize output

-- help: displays the help file

-- version: displays the current version of RPM

The above is just a summary of the common options. If you have any questions, you can check them with the man rpm command. Official documents are always the best teachers.

3. Installation of installation files in * .bin format

Just double-click or click the * .bin file and you can install it according to the prompts.

To make a package in RPM format, you need to write a package description file. Its standard naming format is: software name-version number-release number .spec (now most cases are directly used: software name.spec), this file describes in detail a lot of information about the software package, such as software name, version, category, description summary, what instructions to be executed when creating, what actions to perform during installation, and the files to be included in the software package, and so on. With this file, RPM can make the corresponding package file. Of course, there are also open source package making aids such as Source rpm that can be made with only one program source and the next step through the wizard.

A simple example of production:

In fact, the best way is to make a software package. I remember that both rpm and debian have fast-packaged open source software that can be used directly.

Eg > > make the tar package of nginx as the RPM package

1. Download the source package of nginx

two。 Put the file in the / usr/src/redhat/SOURCES/ directory

3. Write SPEC files

[root@mail SPECS] # vinginx-0.8.35.spec

Summary:the first rpmpackage

Name:nginx

Version:0.8

Release:35

Vendor:chenwei01@corp.the9.com

License:Share

Group:Applications/Text

Source0:nginx-0.8.35.tar.gz

% description

My test nginx

% prep

Tar-zxvf $RPM_SOURCES_DIR/nginx-0.8.35.tar.gz

% build

Cd$RPM_BUILD_DIR/nginx-0.8.35

. / configure

Make

% install

Cd$RPM_BUILD_DIR/nginx-0.8.35

Make install

% clean

Rm-rf$RPM_BUILD_DIR/nginx-0.8.35

% files

% defattr (-, root,root)

/ usr/local/nginx/sbin/nginx

Doc $RPM_BUILD_DIR/nginx-0.8.35/README

4. Make RPM package

[root@mail SPECS] # rpmbuild-ba nginx-0.8.35.spec

If there are no errors in running, two files, / usr/src/redhat/RPMS/i386/nginx-0.8-35.i386.rpm and / usr/src/redhat/SRPMS/nginx-0.8-35.src.rpm, are generated.

Summary: personal experience of how to make rpm packages

An introduction to RPM

RPM used to be the abbreviation of RedHat Package Manager, which originally means RedHat package management, as the name implies, it is the package management contributed by RedHat; now it should be the abbreviation of RPM Package Manager. In Fedora, Redhat, Mandriva, SuSE, YellowDog and other mainstream distributions, as well as in these versions of the secondary development of the release version; RPM package in addition to the program needs to run the file, there are other files; an RPM package of applications, sometimes in addition to its own additional files to ensure that it is normal, but also need other specific version files, this is the package dependency.

RPM allows users to install software packages directly in binary mode, and can query for users whether the relevant library files have been installed; when deleting programs with RPM, it will cleverly ask users whether they want to delete the relevant programs. If you use RPM to upgrade the software, RPM retains the original configuration file so that users do not have to reconfigure the new software. RPM maintains a database that contains information about all the software packages, through which users can query the software packages. Although RPM is designed for Linux, it has been transferred to other UNIX systems such as SunOS, Solaris, AIX, Irix and so on. RPM follows the GPL copyright agreement, and users are free to use and distribute RPM in accordance with the GPL agreement.

Two RPM packet classification

Personally, I think rpm can be divided into two categories.

1 binary package, including rpm installation package (generally divided into i386 and x86, etc.) and mode packet, etc.

2 Source class packages, source packages and development packages should be located in this class.

The relationship between them is that, first of all, we modify the software project source code according to the rpm packaging requirements. After meeting the requirements, we can use the rpmbuild command to generate different rpm packages, and the versions generated at the same time correspond directly to each other. For example, the same source package will generate exactly the same binary rpm package. When you look for rpm packages on the Internet, you can usually find precompiled binaries in the RPMS directory and source packages in the SRPMS directory.

The RPM production we mentioned here refers to the process of transforming the software source code to meet the RPM packaging requirements, which can also be equivalent to the production process of the RPM source package, because when you have the source package, you can directly compile the binary installation package and any other package.

Introduction to the production of three RPM packages

The production of RPM package is the production of RPM source code package.

Here I would like to talk about how RPM packages work, which will contribute to a comprehensive understanding of the RPM package management system.

RPM is to solve the problem that the source package is not easy to install (needs to be compiled) and the software package depends on each other (that is, the RPM package manager can solve the dependency problem to some extent). By detecting the actions of the source package in the build and install phases, it obtains the files in the resulting system that need to be installed, and records some necessary operations (such as performing an operation after the installation is completed), and then integrates this into a whole. When the user installs this package, put all the previously obtained problems and records of all operations on the actual system.

To package RPM for an ordinary source code, you need to do the following. First, you need to make necessary changes to the Makefile of the project to support the RPM packaging operation (in fact, this operation is not absolute. SPEC documents and Makefile are coordinated and unified. As long as they cooperate with each other, it doesn't matter. Generally, we just recommend that you operate in accordance with industry standards as far as possible.) The second is to write the SPEC document for the current project. The SPEC document includes the operation content of the RPM packaging process and the basic information of the newly generated RPM package, and its function object is the packaging program rpmbuild.

The process of making four RPM packages

1 prepare the packing environment

Use the following command to install rpmbuild on the fedora system

# yum install rpmbuild

Rpmbuild's working directory is as follows

~ / rpmbuild

~ / rpmbuild/SOURCES

~ / rpmbuild/SPECS

~ / rpmbuild/BUILD

~ / rpmbuild/RPMS

~ / rpmbuild/RPMS/i386

~ / rpmbuild/SRPMS

If your user directory does not have a similar directory structure under the home directory, you can configure and generate it automatically through a tool, as follows.

# yum installrpmdevtools

Run the automatic configuration command to automatically generate the directory as above, and configure some necessary actions.

# rpmdev-setuptree

By default, the rpmdev-setuptree command will create a RPM build root directory structure under the current user's home directory.

If you need to change the secondary default location, you can change the value of the variable _ topdir in the configuration file: ~ / .rpmmacros.

Generally speaking, rpmbuild will automatically establish the above directory structure under the current user's home directory. If you do not automatically create the above directory in your corresponding user's build directory, you can do it manually. The use of the above directory is allocated like this: SOURCES places packaging resources, including source code packaging files and patch files, etc.; SPECS directory places SPEC documents; BUILD packaging process of the working directory; RPMS directory stores the generated binary package, RPM packages are classified according to hardware platform, i386 means that the i386 structure of the package will be stored in this directory; SRPMS directory stores the generated source code package.

2 write SPEC documents

SPEC writing is the core of packaging RPM, and it is also the most difficult step. Fortunately, we can start with reference to a simple template file, and then expand the document content step by step on the basis of achieving the basic functions, until the requirements are fully met. The following is a simple SPEC document, which contains some explanatory information. The SPEC document is written for a tested software project hellorpm. After the hellorpm package is compiled, there is only one execution file, one manual file and one project description file.

The hellorpm.spec document is as follows:

# brief introduction of software package

Summary: hellorpm is atest program .

# name of the software package

Name: hellorpm

# the major version number of the package

Version:2.2.6

# minor version number of the software package

Release: 1

# Source code package, which will be found in the SOURCES directory mentioned above by default

Source0:% {name} -% {version} .tar.gz

# Authorization Agreement

License: GPL

# define a temporary build directory, which will be referenced later as a temporary installation directory

BuildRoot:% {_ tmppath} /% {name} -% {version} -% {release}-root

# Software classification

Group:Development/Tools

# introduction to the software package

% description

The hellorpm programis a test.

# indicates the pre-operation field, and the following commands will be executed before the source code BUILD

% prep

# build a BUILD environment and unzip the source code to the BUILD directory

% setup-q

# BUILD field, which completes the source code compilation operation by directly calling the automatic build tool in the source code directory

% build

# call the configure command in the source directory

. / configure

# execute the automatic build command make in the source directory

Make

# installation field

% install

# call installation and execution script in source code

MakeDESTDIR=$RPM_BUILD_ROOT install

# File description field, declaration superfluous or missing may make an error

% files

# set file permission attributes

% defattr (-, root,root)

# declare that / usr/local/bin/hellorpm will appear in the package

/ usr/local/bin/hellorpm

# declare and set file properties

% doc%attr (0444 heroine root) / usr/local/man/man1/hellorpm.1

# ditto, declare the document file

% docREADME

There is one point to be noted in this document:

BuildRoot:% {_ tmppath} /% {name} -% {version} -% {release}-root

The above BuildRoot variable represents the temporary directory of the source code. Rpmbuild obtains all the files to be followed in the system through the subdirectory, and the parameter DESTDIR=$RPM_BUILD_ROOT in the make install command after the SPEC document is a reference to this parameter. This parameter will be passed to the Makefile file as soon as it tells the automatic build tool where the installation file should be installed (in fact, the Makefile I mentioned earlier needs to make some modifications to accommodate the RPM build, and your Makefile file should at least know that the value of this parameter is referenced during the RPM build process to control the target of the installation operation).

As the previous simple SPEC document is written, let's put a source zip file named hellorpm-2.2.6.tar.gz into the

Under the SOURCES directory under the root directory of rpmbuild (Note, make sure that the unzipped directory of this archive file is hellorpm-2.2.6, otherwise there will be problems).

Now that a complete rpm packaging environment has been built, we can start building the binary and source RPM packages.

3 build RPM package

Building the RPM package is done with the command rpmbuild under the guidance of SPEC.

To start the build operation, first go to the current user's rpmbuild root (that is, the directory environment mentioned above).

# cd ~ / rpmbuild/

Execute the command how to,-ba means build all, that is, generate all RPM packages including binary packages and source code packages. If normal, rpmbuild will exit normally, and corresponding RPM packages will be generated in the RPMS directory and SRPMS directory.

# rpmbuild-baSPECS/hellorpm.spec

Here only introduces the simplest software of the most simple RPM packaging operation process, such as the packaging of projects with shared files that require complex configuration and complex dependencies, as well as later maintenance, including the production of patches, I will complete supplementary updates in the next time, today is not early, it is time to rest!

Note: it took me most of the night to come up with such an unsatisfactory document. I thought, how meaningful is this? If you dare not reinvent the wheel, you can see farther when you stand on the shoulder of a giant. Is that so? Will you start making a plan next week to translate at least three documents on fedora's official website every week for your own practice?

Thank you for reading! This is the end of this article on "what are the ways to install software in Linux". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

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.