Linux software package management

Linux software package management

If we spend some time in the Linux community, we will know a lot about the class, such as which of the many Linux distributions is the best (and other issues. These discussions focus on such things, such as the most beautiful desktop background (some people do not use Ubuntu, just because the default Ubuntu theme color is brown !) And other trivial things, often become very boring.

The most important factor determining the quality of Linux releases is the persistence of the software package management system and its support community. As we spend more time on Linux, we will find that its software park is very dynamic. Software is constantly changing. Most first-line Linux releases a new version every six months, and many independent programs are updated every day. To keep in touch with a lot of software such as Blizzard, we need some good tools for software package management.

Software Package management is a method of installing and maintaining software in the system. Today, software packages installed in Linux distributions can meet all the needs of many people. This is different from the early Linux systems. People need to download and edit the source code to install the software. There is no problem in editing the source code. In fact, having access to the source code is a great miracle of Linux. It gives us (everyone else) the ability to detect and improve system performance. It is easier to process a pre-compiled software package. In this chapter, we will view some command line tools for package management. Although all mainstream Linux distributions provide powerful and sophisticated graphics management programs to maintain the system, it is also important to learn the command line program. Because they can complete many tasks that make it difficult (or impossible) for graphical management programs to process.

Packaging System

Different Linux distributions use different packaging systems. Generally, most distributions belong to the two major package management technology camps: Debian's ". deb" and Red Hat ". rpm ". There are also some important exceptions, such as Gentoo, Slackware, and Foresight, but most of them will use one of these two basic systems.

Table 15-1: main package management system families

Package Management System	Release (partial list)
Debian Style (. deb)	Debian, Ubuntu, Xandros, Linspire
Red Hat Style (. rpm)	Fedora, CentOS, Red Hat Enterprise Linux, OpenSUSE, Mandriva, PCLinuxOS

How does the software package management system work?

The software release method found in the proprietary software industry usually requires buying an installation media, such as an "installation disk", and then running the "Installation Wizard" to install new applications in the system.

This is not true for Linux. Almost all software in Linux can be found on the Internet. Most of the software is provided by the publisher in the form of package files, and the rest are in the form of source code, which can be manually installed. In the subsequent sections, we will talk about how to install software by compiling the source code.

Package files

In the package management system, the basic unit of software is package files. A package file is a collection of compressed files that constitute a software package. A software package may consist of a large number of programs and data files that support these programs. In addition to the installation file, the package file also contains metadata about the package, such as a text description of the package and its content. In addition, many software packages include pre-installed and post-installed scripts used to execute configuration tasks before and after software installation.

A software package file is created by the software package maintainer, who is usually (but not always) an employee of a software publisher. The software maintainer obtains the software source code from the upstream provider (Program author), then edits the source code, creates the software package metadata and the required installation script. Generally, the software package maintainer applies the modifications made to the original source code to improve the integration of the software with other parts of the Linux release.

Resource Library

Although some software projects choose to execute their own packaging and release policies, most software packages are now created by publishers and interested third parties. Users of the system release version can obtain these software packages in a central resource library, which may contain thousands of software packages, each of which is specially created and maintained for the system release version.

A distribution may maintain several different repositories for different stages of the software development life cycle. for example, there will usually be a "testing" repository that contains packages that have just been built and are intended for use by brave souls who are looking for bugs before they are released for general distribution. A distribution will often have a "development" repository where work-in-progress packages destined for future sion in the distribution's next major release are kept.

Due to the needs of different stages of the software development lifecycle, a system release may maintain several different resource libraries. For example, there is usually a "test" resource library that contains the software packages just created. They are intended to be used by brave users. Before these software packages are officially released, users can find errors. The system release version often has a "development" resource library, which stores semi-finished software packages destined to be included in the next major version.

A system release may also have a third-party resource library. These resource libraries need to support software that cannot be included in the release edition due to legal reasons, such as patent or DRM anti-avoidance issues. Perhaps the most famous case is the encrypted DVD support, which is illegal in the United States. Third-party resource libraries play a role in countries where these software patents and anti-fraud laws do not take effect. These resource libraries are generally completely independent from the resources they support. To use them, you must understand them and manually include them in the configuration files of the software package management system.

Dependency

Programs are rarely "isolated", but rely on other software components to complete their work. Common activities are handled by sharing program routines using input/output as an example. These program routines are stored in the shared library. The shared library not only provides basic services for a program. If a software package needs to share resources, such as a shared library, it is said that there is a dependency. The modern software package management system provides some dependency parsing methods to ensure that all of the dependencies are installed when the software package is installed.

Upper and lower layer software package tools

A software package management system usually consists of two types of tools: the underlying tools are used to process these tasks, such as installing and deleting software package files, and the upper-layer tools to complete metadata search and dependency parsing. In this chapter, we will take a look at the tools provided by Debian systems (such as Ubuntu and many other systems) and those used by Red Hat products. Although all Red Hat-style releases depend on the same underlying Program (rpm), they use different upper-layer tools. We will study the upper-Layer Program yum for our discussion. Both Fedora, Red Hat Enterprise Edition, and CentOs use yum. Other Red Hat-style releases provide upper-layer tools with comparable features.

Table 15-2: package management tools

Release	Underlying tools	Upper-layer tools
Debian-Style	Dpkg	Apt-get, aptitude
Fedora, Red Hat Enterprise Linux, CentOS	Rpm	Yum

Common Software Package management tasks

You can perform many operations using the command line software package management tool. We will take a look at the most commonly used tools. Note that underlying tools also support the creation of Software Package files. This topic is beyond the scope described in this book. In the following discussion, the term "package_name" refers to the actual name of the software package, rather than package_file, which is the file name included in the software package.

Find software packages in the resource library

Use the upper-layer tool to search for the metadata of the resource library. You can locate the metadata based on the package name and description.

Table 15-3: search tool for software packages

Style	Command
Debian	Apt-get update; apt-cache search search_string
Red Hat	Yum search search_string

For example, to search for a yum resource library to find the emacs text editor, run the following command:

Yum search emacs

Install a software package from the resource library

The upper-layer tool allows you to download a software package from a resource library and install it after full dependency parsing.

Table 15-4: package installation commands

Style	Command
Debian	Apt-get update; apt-get install package_name
Red Hat	Yum install package_name

For example, install the emacs text editor from an apt resource library:

Apt-get update; apt-get install emacs

Install software using the package file

If you download a software package file from somewhere rather than from the resource library, you can use the underlying tool to install it directly (without dependency parsing.

Table 15-5: Installation commands for underlying software packages

Style	Command
Debian	Dpkg -- install package_file
Red Hat	Rpm-I package_file

For example, if you have downloaded the package file emacs-22.1-7.fc7-i386.rpm from a website that is not a repository, you can install it in this way:

Rpm-I emacs-22.1-7.fc7-i386.rpm

Note: Because this technology uses the underlying rpm program to execute the installation task, it does not run dependency parsing. If the rpm program finds that a dependency is missing, an error is reported and the program exits.

Uninstall Software

You can use upper-layer or bottom-layer tools to uninstall software. The following are available upper-layer tools.

Table 15-6: Software Package deletion commands

Style	Command
Debian	Apt-get remove package_name
Red Hat	Yum erase package_name

For example, detach an emacs package from a Debian system:

Apt-get remove emacs

Update the software package through the resource library

The most common software package management task is to keep the software packages in the system up-to-date. The upper-layer tool can complete this crucial task in only one step.

Table 15-7: Software Package update command

Style	Command
Debian	Apt-get update; apt-get upgrade
Red Hat	Yum update

For example, update a software package installed in a Debian system:

Apt-get update; apt-get upgrade

Upgrade software through software package files

If you have downloaded the latest version of a software package from a non-resource library website, you can install it to replace the previous version:

Table 15-8: underlying software package upgrade commands

Style	Command
Debian	Dpkg -- install package_file
Red Hat	Rpm-U package_file

For example, update the version of emacs installed in the Red Hat system to the version of emacs included in the emacs-22.1-7.fc7-i386.rpmz of the package file.

Rpm-U emacs-22.1-7.fc7-i386.rpm

Note: The options used by the rpm program to install a software package are different from those used to upgrade a software package, while the options used by the dpkg program are the same.

List Installed Software Packages

The commands in the following table can be used to display the list of all software packages installed on the system:

Table 15-9: List Installed Package commands

Style	Command
Debian	Dpkg -- list
Red Hat	Rpm-qa

Are you sure you have installed a software package?

These bottom tools can be used to show whether a specified software package is installed:

Table 15-10: package status commands

Style	Command
Debian	Dpkg -- status package_name
Red Hat	Rpm-q package_name

For example, check whether the emacs package is installed in a Debian system:

Dpkg -- status emacs

Displays information about the installed software package.

If you know the name of the installed software package, use the following command to display the description of the software package:

Table 15-11: Command for viewing package information

Style	Command
Debian	Apt-cache show package_name
Red Hat	Yum info package_name

For example, view the description of the emacs software package in a Debian system:

Apt-cache show emacs

Find the software package where a file is installed

Determine which software package is responsible for a special file installed. Use the following command:

Table 15-12: Packet file recognition commands

Style	Command
Debian	Dpkg -- search file_name
Red Hat	Rpm-qf file_name

For example, in the Red Hat system, check which software package has the/usr/bin/vim file installed.

Rpm-qf/usr/bin/vim

Summary

In the subsequent sections, we will explore many different programs that cover a wide range of application fields. Although most programs are installed by default, if the required programs are not installed in the system, we may need to install additional software packages. With our new (and known) software package management knowledge, we should have no problem installing and managing the required programs.

Rumors about installing Linux software

Users who migrate data from other platforms sometimes become victims of rumors that installing software is difficult in Linux systems, in addition, the various packaging solutions used by different system releases are an obstacle. Alas, it's a barrier, but it's only for proprietary software vendors who want to release their secret software in binary.

The Linux software ecosystem is based on the Open Source Concept. If a program developer releases the source code of a product, the developer associated with the system release may package the product, and include it in their resource library. This method ensures that this product can be well integrated with the system release version, while providing users with the convenience of "one-stop purchasing" software, so that users do not have to search for the website of each product.

Device Drivers are also processed in the same way, but they are not a separate project in the system release repository, and they are part of the Linux system kernel. In general, there is no such thing as a "drive disk" in Linux. If the kernel supports one device or not, the Linux kernel supports many devices. In fact, it is more than the number of devices supported by Windows. Of course, there is no comfort if the specified device you need is not supported. When that happens, you need to find the cause. Lack of driver support is typically caused by one of the following three situations:

1. the device is too new. Because many hardware vendors do not actively support the development of Linux, the task of writing kernel-driven code is undertaken by some Linux communities, which takes time.

2. the device is too strange. Not all releases contain every possible device driver. Each release builds their own kernel because the kernel can be configured (this makes it possible to run Linux on each device from the watch to the host ), in this way, they may ignore a special device. By locating and downloading the driver source code, you may need to compile and install the driver yourself (yes, you. This process is not difficult, but involved. We will discuss software compilation in the subsequent sections.

3. hardware supplier hiding information. They neither publish driver code for Linux systems nor publish technical documents to let someone create it. This means that the hardware supplier tries to keep the program interface of the device confidential. Because we do not want to use confidential devices in computers, we recommend that you delete this nasty software and keep it and other useless items in the trash.

Additional reading

Spend some time getting to know the package management system for your distribution. Each distribution provides documentation for its package management tools. In addition, here are some more generic sources:

Take some time to understand the software package management system in your release. Each release provides documentation on the built-in software package management tools. In addition, there are some more common resources:

Debian GNU/Linux FAQ the software package management chapter provides an overview of software package management:

Http://www.debian.org/doc/FAQ/ch-pkgtools.en.html

The home page for the RPM project:

Home page of the RPM project:

Http://www.rpm.org

The home page for the YUM project at Duke University:

Duke University YUM project home page:

Http://linux.duke.edu/projects/yum/

For a little background, the Wikipedia has an article on metadata:

I have some background knowledge. Wikipedia has an article about metadata:

Http://en.wikipedia.org/wiki/Metadata

This article permanently updates the link address: