|
 |
|
| |
2. Software Management Concepts
CentOS software and documentation is supplied in the form of
files called RPM packages. Each package
is a compressed archive containing product information, program
files, icons, documentation and management scripts. Management
applications use these files to safely locate, install, update
and remove software. For example, the CentOS installation process
uses the packages supplied with CentOS to build or upgrade a
system to your requirements.
Packages also include a digital signature to prove their source.
Software management utilities verify this digital signature by
using a GPG public key. The
yum and rpm utilities
share a common keyring that stores all of
the public keys for approved package sources. The system
administrator configures these approved package sources.
A repository is a prepared directory or
web site that contains software packages and index files.
Software management utilities such as yum
automatically locate and obtain the correct RPM packages from
these repositories. This method frees you from having to
manually find and install new applications or updates. You may
use a single command to update all system software, or search
for new software by specifying criteria.
The package management utilities in CentOS are already configured
to use a network of servers that provide several repositories:
[base] (AKA [os]) - The packages that make up CentOS, as it is released on the ISOs. It is enabled by default.
[updates] - Updated packages to [base] released after the CentOS ISOs. This will be Security, BugFix, or Enhancements to the [base] software. It is enabled by default.
[addons] - Contains packages required in order to build the main Distribution or packages produced by SRPMS built in the main Distribution, but not included in the main Redhat package tree (mysql-server in CentOS-3.x falls into this category). Packages contained in the addons repository should be considered essentially a part of the core distribution, but may not be in the upstream Package tree. It is enabled by default.
[contrib] - Packages contributed by the CentOS Users, which do not overlap with any of the core Distribution packages. These packages have not been tested by the CentOS developers, and may not track upstream version releases very closely. It is disabled by default.
[centosplus] - Packages contributed by CentOS Developers and the Users. These packages might replace rpm's included in the core Distribution. You should understand the implications of enabling and using packages from this repository. It is diabled by default
[csgfs] - Packages that make up the Cluster Suite and Global File System. It is disabled by default.
[extras] - Packages built and maintained by the CentOS developers that add functionality to the core distribution. These packages have undergone some basic testing, should track upstream release versions fairly closely and will never replace any core distribution package. It is enabled by default.
[testing] - Packages that are being tested proir to release, you should not use this repository except for a specific reason. It is disabled by default.
| ![[Note]](HEADER.images/note.png) | All CentOS Packages are Open Source Software |
|---|
All of the software provided by the CentOS Project is open source
software. You may download and install software from the CentOS Project
network of repositories on as many systems as desired.
|
Third-party software developers also provide repositories for
their CentOS compatible packages. To learn how to configure your
CentOS system to use third-party repositories, read
Section 7, “Using Other Software Repositories”.
You may also use the package groups
provided by the CentOS repositories to manage related packages as
sets. Some third-party repositories add packages to these
groups, or provide their packages as additional groups.
| Available Package Groups |
|---|
To view a list of all of the available package groups for your
CentOS system, run the command su -c 'yum
grouplist'.
|
Use repositories to ensure that you always receive current
versions of software. If several versions of the same package
are available, your management utility automatically selects the
latest version.
![[Caution]](HEADER.images/caution.png) | Installing Software not from a Repository |
|---|
Install software using manual methods only when you are
confident there is no repository which can currently provide
it. You may have to manage that software with manual methods,
instead of with CentOS software management utilities.
The yum commands shown in this document use
repositories as package sources. Refer to
Section 9, “Manually Installing Software” for details of
using yum to install software from a
package file.
|
Some of the files installed on a CentOS distribution are
libraries which may provide functions to
multiple applications. When an application requires a specific
library, the package which contains that library is a
dependency. To properly install a
package, CentOS must first satisfy its dependencies. The
dependency information for a RPM package is stored within the
RPM file.
The yum utility uses package dependency data
to ensure that all of requirements for an application are met
during installation. It automatically installs the packages for
any dependencies not already present on your system. If a new
application has requirements that conflict with existing
software, yum aborts without making any
changes to your system.
2.4. Understanding Package Names
Each package file has a long name that indicates several key
pieces of information. This is the full name of the
tsclient package supplied with CentOS:
tsclient-0.132-4.i386.rpm
Management utilities commonly refer to packages with one of
three formats:
For clarity, yum lists packages in the format
name.architecture. Repositories also
commonly store packages in separate directories by architecture.
In each case, the hardware architecture specified for the
package is the minimum type of machine
required to use the package.
-
i386
Suitable for any current Intel®-compatible computer
-
noarch
Compatible with all computer architectures
-
ppc
Suitable for PowerPC systems, such as Apple® Power
Macintosh or IBM® PowerPC
-
ia64
Suitable for Intel® Itanium2 processors.
-
s390 or s390x
Suitable for IBM® S390 or S390x Processors.
-
alpha
Suitable for DEC® alpha Processors (now owned by Hewlitt Packard®).
-
sparc
Suitable for Sun Microsystems® sparc Processors.
-
x86_64
Suitable for 64-bit Intel-compatible processors, such as
AMD® Opteron or Intel® Xeon Processors
Some software may be optimized for particular types of
Intel-compatible machine. Separate packages may be provided for
i386, i586,
i686 and x86_64 computers. A
machine with at least an Intel® Pentium, VIA® C3 or compatible CPU
may use i586 packages. Computers with an Intel®
Pentium Pro® and above, or a current model of AMD® chip, may use
i686 packages.
Use the short name of the package for yum
commands. This causes yum to automatically
select the most recent package in the repositories that matches
the hardware architecture of your computer.
Specify a package with other name formats to override the
default behavior and force yum to use the
package that matches that version or architecture. Only override
yum when you know that the default package
selection has a bug or other fault that makes it unsuitable for
installation.
![[Tip]](HEADER.images/tip.png) | Package Names |
|---|
You may use any of the following formats to specify a package
in a yum operation:
name,
name.architecture,
name-version,
name-version-release,
name-version-release.architecture,
and
epoch:name-version-release.architecture.
|
|
|
