In general, there are three main methods for installing software in Linux: one is source code installation, and you need to manually compile the other is RPM packet (RedHatLinuxPacket
In general, there are three main methods for installing software in Linux:
One is source code installation, which requires manual compilation by the user
The other is the RPM Package (RedHat Linux Packet Manager), which can be installed through the RPM command.
Another method is the *. binfile, which is similar to the installation process in Windows.
Generally, the following two methods are used to install software in Linux:
① The file name is like xxx. i386.rpm. the software package is released in binary format.
② The file name is like xxx.tar.gz. the software package is released in the form of source code.
Linux software package management can be divided into three types: binary package management, source code package management, script installation
In addition, it is worth noting that there are many ways to obtain and install software for various Linux releases.For example
[] Redhat/centos yum installation (with dedicated image sources)
[] Sudo apt-get of Ubuntu/Fedora/Debian is suitable for managing and installing deb packages.
[] Some software is installed with an encrypted disk (for example, cnyunwei)
[] In terms of system O & M management personnel, some software commands executed in ssh, C/C ++, or py are also used for automated management. I will not detail them here.
The following figure shows the architecture relationship of linux software applications:
When Linux is started. The kernel is a computer program that directly manages hardware, including CPU, memory space, hard disk interface, and network interface. All computer operations must be passed to the hardware through the kernel. We can see that Linux uses kernel to implement a conversation between hardware and software. Through this important interface called by the system, Linux completely separates upper-layer applications from lower-layer kernel, hiding the underlying complexity for programmers (correspondingly, it also improves the portability of upper-layer applications ). When upgrading the kernel, we can also keep the statements called by the system unchanged, so that upper-layer applications do not feel the changes at the lower layer. Library functions use system calls to create modular functions, while shell provides a user interface, allowing us to write scripts using shell syntax to integrate the program. With these ideas, we can quickly understand the installation and working principles of linux software applications, therefore, in order to facilitate and obtain more enterprise applications, we need to develop various software packages on the linux system and compile the source code to serve the information age.
This article describes how to install source code and RPM packages.
The source code package and commercial software package are based on the actual situation of each company or author (it can be a compressed package in tar or bin format, it can be a compiled file that can be directly used for running, or an iso file that can be created and released by other media such as the disc Virtualization file) package it into a specific format and release it for corresponding software services. In fact, software installed using the yum or make install command will automatically generate an rpm package in the system (only the differences and rigor between parameters and functional modules)
Introduction:
RPM (RedHat Package Manager, Red Hat Package Manager) is used before installing, querying, upgrading, verifying, uninstalling software packages, and generating software packages in. rpm format RPM.
You can also download the free RPM package from the Internet.
# Mount/dev/cdrom --- attach a CD
# Cd/media/cdrom/CentOS/RPMS --- enter the RPM package directory on the disc (you can run the # mount command to check that the mount point of the disc is usually displayed on the last line)
# Ls
I. install the source code package
1. * Source Code package in the form of src. rpm
Usage:
Install: rpm-rebuild *. src. rpm
Cd/usr/src/dist/RPMS
Rpm-ivh *. rpm
Uninstall: rpm-e packagename
22.16.tar.gz, *. tgz, *. bz2 software package installation
First, decompress the package. the command is as follows:
Tar zxvf * .tar.gz
Tar xvfz *. tgz
Tar xvfj * .tar.bz2
Decompress the package and enter the decompressed directory)
Configuration:./configure
Compile: make
Install: make install
Uninstall: make uninstall
It is difficult to install the source code. different software may be installed differently. Generally, you should read the instructions and install the software according to the instructions.
II. RPM Package installation
The RPM installation package format was proposed by Redhat, which greatly simplifies the installation of software in Linux. First, we will introduce general options.
-V: displays additional information.
-Vv: displays debugging information.
-- Root directory: let RPM use directory as the root directory, so that both the preinstallation program and the post-installation program will be installed in this directory.
1. Installation: rpm-I File. rpm
Options:
H: output hash mark during installation
Test: only tests the installation and does not install it.
-- Persent: displays the installation progress in percentages.
-- Excludedocs: does not install the document in the software package
-- Replacepkgs: force reinstall
-- Replacefiles: replace the files of other software packages.
-- Force: ignore software packages and document conflicts
-- Ignorearch: the structure of the software package is not verified.
-- Ignoreos: the operating system that does not check the software package running
-- Nodeps: no dependency check
-- Noscripts: do not run the pre-installation and post-installation scripts
2. delete rpm-e Pkgname
Option:
-- Test: only deletes the test and does not actually delete the test.
-- Noscripts: do not run the pre-installation and post-installation scripts
-- Nodeps: no dependency check
Note: pkgname is the package name, not the rpm Package name, but the package name after installation. you can use the query command to query the package name.
3. upgrade rpm-U (or-upgrade) File. rpm
Option:
Similar to the option during installation, there are several special features:
-- Oldpackage: allows an old version
4. query rpm-q (or -- query)
Option:
-P PACKAGE_FILE: query the package file
-F FIEL: queries the software package of the FILE.
-A: query all installed software packages.
-G group: queries software packages that belong to the group.
-- WhatproVidesCAPABILITY: queries software packages that provide CAPABILITY.
-- WhatrequiresCAPABILITY: queries all software packages that require CAPABILITY.
-I: displays the summary of the software package.
-L: displays the file list in the software package.
-C: displays the configuration file list.
-S: displays the file list
-Scripts: displays the installation, uninstallation, and validation scripts.
-- Qf: queries in the way specified by the user
-- Dump: displays the verification information for each file.
-- ProVides: displays the functions provided by the software package.
-R: displays the functions required by the software package.
5. verify the installed software package rpm-V (or-verify, or-y)
The Option is similar to that of other commands.
6. verify the file rpm-K (or-checksig) in the software package) File. rpm
Option:
-V: displays version information.
-Vv: displays debugging information.
-- Rcfile FILELIST: sets the rpmrc file to FILELIST.
7. other RPM options
-- Rebuilddb: rebuilding the RPM database
-- Initdb: create a new RPM database
-- Quiet: reduce output as much as possible
-- Help: displays the help file.
-- Version: displays the current version of RPM.
The above is just a summary of common options. if you have any questions, you can use the man rpm command to view them. the official file will always be the best teacher.
III. installation of *. bin installation files
You only need to double-click the *. binfile to install it as prompted.
To create a software package in RPM format, you need to compile the software package description file. The standard naming format is: software name-version number-release number. spec (usually used directly in most cases: software name. spec). This file describes a lot of information about the software package, such as the software name, version, category, description summary, what commands to execute during creation, and what operations to perform during installation, and the files to be included in the software package. With this file, RPM can produce the corresponding package file. Of course, there are also open-Source package preparation tools such as Source rpm, which can be created through the wizard as long as a program Source.
A simple example:
In fact, the best way is to make a software package. I remember that both rpm and debian have open-source software that can be quickly packaged and used directly.
Eg> use nginx tar as the RPM Package
1. download the nginx source code package
2. put the file in the/usr/src/redhat/SOURCES/directory.
3. Compile the SPEC file
[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. create an RPM Package
[Root @ mail SPECS] # rpmbuild-ba nginx-0.8.35.spec
If there is no error running, two files are generated:/usr/src/redhat/RPMS/i386/nginx-0.8-35.i386.rpm and/usr/src/redhat/SRPMS/nginx-0.8-35.src.rpm.
Summary: how to create an rpm Package
1 RPM introduction
RPM is the abbreviation of RedHat Package Manager. it is intended to be the management of Red Hat software packages. as the name suggests, it is the management of software packages contributed by Red Hat. now it should be the abbreviation of RPM Package Manager. Mainstream release versions such as Fedora, Redhat, Mandriva, SuSE, and YellowDog, as well as the release versions developed on the basis of these versions. The RPM package includes the files required for running the program, there are also other files; an RPM package application sometimes requires other specific versions of files in addition to the additional files it carries to ensure its normality. this is the dependency of the software package.
RPM allows you to directly install the software package in binary mode and query whether the related library files have been installed for you. when you delete a program using RPM, it also intelligently asks the user whether to delete the relevant program. If you use RPM to upgrade the software, RPM retains the original configuration file so that you do not need to reconfigure the new software. RPM retains a database that contains all the software package materials. through this database, you can query the software package. Although RPM is designed for Linux, it has been moved to SunOS, Solaris, AIX, Irix and other UNIX systems. RPM complies with the GPL copyright agreement, and users can freely use and disseminate RPM under the conditions that comply with the GPL protocol.
Binary RPM Package classification
In my opinion, rpm is divided into two categories,
1 binary package, including rpm installation package (generally divided into i386 and x86) and debugging information package.
2. the Source Code package, the source code package and the development kit should be replaced with this class.
The relationship between them is that we first need to modify the software project source code according to rpm packaging requirements. when the requirements are met, we can use the rpmbuild command to generate different rpm packages, the versions generated at the same time correspond directly to each other. for example, if the source code package is the same, a binary rpm Package is generated. When you search for rpm packages online, you can find pre-compiled binary packages in the RPMS Directory, while the source code package is in the SRPMS directory.
The RPM production mentioned here refers to the process of modifying the software source code to meet RPM packaging requirements. This can also be equivalent to the RPM source code package production process, because when you have the source code package, you can directly compile the binary installation package and any other packages.
Introduction to making three RPM packages
Create an RPM package, that is, create an RPM source package.
Here I want to talk about how the RPM package works. This will help you fully understand the RPM package management system.
RPM is used to solve the problem that the source package is not easy to install (requires compilation) and the software package is dependent on each other (the RPM Package Manager can solve the dependency problem to a certain extent, it obtains the final generated file in the system to be installed by detecting the actions of the source code package in the build and install phases, record the necessary operations (for example, execute an operation after installation), and then combine them into a whole, when the user installs this package, it will take effect on the actual system for all the problems and operations recorded previously.
To pack RPM for a common source code, you need to perform the following operations. First, you need to make necessary modifications to the project Makefile to support the RPM packaging operation (in fact, this operation is not absolute, SPEC documents and Makefile are coordinated and unified. it doesn't matter if they work together. we generally recommend that you follow industry standards and specifications as much 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. its role object is the package program rpmbuild.
4 RPM package creation process
1. prepare the packaging environment
Run the following command in the fedora system to install rpmbuild:
# Yum install rpmbuild
The rpmbuild 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, you can use a tool software to automatically configure and generate the directory, as shown below.
# Yum installrpmdevtools
Run the automatic configuration command to automatically generate the above directory and configure some necessary operations.
# Rpmdev-setuptree
By default, the rpmdev-setuptree command creates an RPM in the current user's home directory to build the root directory structure,
If you need to change the default location, you can modify the configuration file :~ /. The value corresponding to _ topdir in rpmmacros.
Generally, rpmbuild automatically creates the above directory structure under the current user's home directory. if the above directory is not automatically created in the build directory of your corresponding user, you can create it manually. The above directory is allocated in this way. SOURCES places packaging resources, including source package files and patch files; SPECS directory places SPEC documents; BUILD working directory during packaging; the RPMS Directory stores the generated binary package. The RPM Package is classified based on the hardware platform. i386 indicates that the packages with the i386 structure will be stored in this directory. the SRPMS Directory stores the generated source 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 by referring to a simple template file, expand the document content step by step on the basis of the basic functions that can be implemented until the requirements are fully met. The following is a simple SPEC document, which includes some instructions (note: # The following content is the description). This 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 content of the hellorpm. spec document is as follows:
-----------------------------------------------------------------------------
# Brief introduction to the software package
Summary: hellorpm is atest program.
# Package name
Name: hellorpm
# Major version number of the software package
Version: 2.2.6
# Minor version number of the software package
Release: 1
# Source Code package, which will be searched in the SOURCES directory mentioned above by default
Source0: % {name1_-1_version=.tar.gz
# Authorization protocol
License: GPL
# Define the temporary build directory, which will be referenced later as the temporary installation directory
BuildRoot: % {_ tmppath}/% {name}-% {version}-% {release}-root
# Software classification
Group: Development/Tools
# Description of the software package
% Description
The hellorpm programis a test.
# Indicates the pre-operation field. the subsequent commands will be executed before the source code BUILD.
% Prep
# BUILD the BUILD environment, decompress the source code package to the BUILD directory
% Setup-q
# The BUILD field will be compiled by directly calling the automatic BUILD tool in the source code directory
% Build
# Call the configure command in the source code directory
./Configure
# Execute the automatic build command make in the source code directory
Make
# Installation field
% Install
# Install and execute the script in the source code
MakeDESTDIR = $ RPM_BUILD_ROOT install
# Errors may occur if the file description field is redundant or missing.
% Files
# Setting file permission attributes
% Defattr (-, root, root)
# Declare/usr/local/bin/hellorpm to appear in the package
/Usr/local/bin/hellorpm
# Declare and set file attributes
% Doc % attr (0444, root, root)/usr/local/man/man1/hellorpm.1
# Same as above, declare a document file
% DocREADME
-------------------------------------------------------------------------------
One point to note in this document:
BuildRoot: % {_ tmppath}/% {name}-% {version}-% {release}-root
The preceding BuildRoot variable indicates the temporary directory of the source code. rpmbuild obtains all the files to be retrieved from the system through the sub-directory, the parameter DESTDIR = $ RPM_BUILD_ROOT in the make install command after the SPEC file is a reference to this parameter, this parameter will be passed to the Makefile file. 1. the automatic build tool should install the file. (in fact, the Makefile I mentioned earlier must be transformed to adapt to RPM construction. this operation is included, in your Makefile file, you must at least know the value of this parameter referenced during RPM build to control the installation operation target ).
Compile a simple spec文, and put a compressed source code file named hellorpm-2.2.6.tar.gz
The SOURCES directory under the rpmbuild root directory (note, make sure that the directory after decompression of this archive file is hellorpm-2.2.6, otherwise there will be issues ).
By now, the complete rpm packaging environment has been built. now we can start to build the binary and source code RPM packages.
3. create an RPM Package
The RPM Package is built with the command rpmbuild completed under SPEC guidance.
Start the build operation. First, go to the rpmbuild root directory of the current user (that is, the Directory environment mentioned above ).
# Cd ~ /Rpmbuild/
-Ba indicates build all, that is, all RPM packages including the binary package and source code package are generated. if the command runs normally, rpmbuild exits normally, at the same time, the corresponding RPM package will be generated in the RPMS directory and SRPMS directory.
# Rpmbuild-baSPECS/hellorpm. spec
Here we only introduce the simplest RPM packaging process of the simplest software, for example, if a project with shared files needs to carry out complex configurations with complex dependencies, and so on, packaging and post-maintenance, including patch creation, I will complete additional updates at the next time, it's not too early today. it's time to rest!
Note: After a long time in the middle of the night, how much is the significance of such an unsatisfactory document? Do you dare not reinvent the wheel and stand on the shoulders of giants before you can see farther, right? Is it possible to set up a plan next week and translate at least three documents on the fedora official website every week for your trainer.
