systemd
Daemonjournalctl
: Query the systemd
Journaludev
This chapter describes Zypper and RPM, two command line tools for
managing software. For a definition of the terminology used in this
context (for example, repository
,
patch
, or update
) refer to
Book “Start-Up”, Chapter 9 “Installing or Removing Software”, Section 9.1 “Definition of Terms”.
Zypper is a command line package manager for installing, updating and removing packages a well as for managing repositories. It is especially useful for accomplishing remote software management tasks or managing software from shell scripts.
The general syntax of Zypper is:
zypper[--global-options]
command[--command-options]
[arguments]
...
The components enclosed in brackets are not required. See zypper
help
for a list of general options and all commands. To get
help for a specific command, type zypper help
command.
The simplest way to execute Zypper is to type its name, followed by a command. For example, to apply all needed patches to the system type:
zypper patch
Additionally, you can choose from one or more global options by typing
them immediately before the command. For example,
--non-interactive
means running the command without
asking anything (automatically applying the default answers):
zypper --non-interactive patch
To use the options specific to a particular command, type them right
after the command. For example,
--auto-agree-with-licenses
means applying all needed
patches to the system without asking to confirm any licenses (they will
automatically be accepted):
zypper patch --auto-agree-with-licenses
Some commands require one or more arguments. When using the install command, for example, you need to specify which package(s) to install:
zypper install mplayer
Some options also require an argument. The following command will list all known patterns:
zypper search -t pattern
You can combine all of the above. For example, the following command will
install the aspell-de
and
aspell-fr
packages from the
factory
repository while being verbose:
zypper -v install --from factory aspell-de aspell-fr
The --from
option makes sure to keep all repositories
enabled (for solving any dependencies) while requesting the package from
the specified repository.
Most Zypper commands have a dry-run
option that does a
simulation of the given command. It can be used for test purposes.
zypper remove --dry-run MozillaFirefox
Zypper supports the global --userdata
string
option. You can specify a
string with this option, which gets written to Zypper's log files and
plug-ins (such as the Btrfs plug-in). It can be used to mark and identify
transactions in log files.
zypper --userdata string patch
To install or remove packages use the following commands:
zypper install package_name zypper remove package_name
Zypper knows various ways to address packages for the install and remove commands.
zypper install MozillaFirefox
or
zypper install MozillaFirefox-3.5.3
zypper install mozilla:MozillaFirefox
Where mozilla
is the alias of the repository from
which to install.
The following command will install all packages that have names starting with “Moz”. Use with care, especially when removing packages.
zypper install 'Moz*'
-debuginfo
Packages
When debugging a problem, you sometimes need to temporarily install a lot of -debuginfo
packages which give you more information about running processes.
After your debugging session finishes and you need to clean the environment, run the following:
zypper remove '*-debuginfo'
For example, if you want to install a Perl module without knowing the name of the package, capabilities come in handy:
zypper install firefox
Together with a capability you can specify an architecture (such as
x86_64
) and/or a version. The version must be
preceded by an operator: <
(lesser than),
<=
(lesser than or equal),
=
(equal), >=
(greater
than or equal), >
(greater than).
zypper install 'firefox.x86_64' zypper install 'firefox>=3.5.3' zypper install 'firefox.x86_64>=3.5.3'
You can also specify a local or remote path to a package:
zypper install /tmp/install/MozillaFirefox.rpm zypper install http://download.opensuse.org/repositories/mozilla/SUSE_Factory/x86_64/MozillaFirefox-3.5.3-1.3.x86_64.rpm
To install and remove packages simultaneously use the
+/-
modifiers. To install
emacs
and remove vim
simultaneously, use:
zypper install emacs -vim
To remove emacs
and install
vim
simultaneously, use:
zypper remove emacs +vim
To prevent the package name starting with the -
being
interpreted as a command option, always use it as the second argument. If
this is not possible, precede it with --
:
zypper install -emacs +vim # Wrong zypper install vim -emacs # Correct zypper install -- -emacs +vim # same as above zypper remove emacs +vim # same as above
If (together with a certain package) you automatically want to remove any
packages that become unneeded after removing the specified package, use
the --clean-deps
option:
zypper rm package_name --clean-deps
By default, Zypper asks for a confirmation before installing or removing
a selected package, or when a problem occurs. You can override this
behavior using the --non-interactive
option. This option
must be given before the actual command (install
,
remove
, and patch
) as in the
following:
zypper --non-interactive
install package_name
This option allows the use of Zypper in scripts and cron jobs.
Do not remove packages such as glibc
,
zypper
, kernel
, or
similar packages. These packages are mandatory for the system and, if
removed, may cause the system to become unstable or stop working
altogether.
If you want to install the corresponding source package of a package, use:
zypper source-install package_name
That command will also install the build dependencies of the specified
package. If you do not want this, add the switch -D
.
To install only the build dependencies use -d
.
zypper source-install -D package_name # source package only zypper source-install -d package_name # build dependencies only
Of course, this will only work if you have the repository with the source packages enabled in your repository list (it is added by default, but not enabled). See Section 2.1.5, “Managing Repositories with Zypper” for details on repository management.
A list of all source packages available in your repositories can be obtained with:
zypper search -t srcpackage
You can also download source packages for all installed packages to a local directory. To download source packages, use:
zypper source-download
The default download directory is
/var/cache/zypper/source-download
. You can change
it using the --directory
option. To only show missing
or extraneous packages without downloading or deleting anything, use the
--status
option. To delete extraneous source packages,
use the --delete
option. To disable deleting, use the
--no-delete
option.
Normally you can only install packages from enabled repositories. The
--plus-content tag
option
helps you specify repositories to be refreshed, temporarily enabled during
the current Zypper session, and disabled after it completes.
For example, to enable repositories that may provide additional
-debuginfo
or -debugsource
packages, use --plus-content debug
. You can specify this
option multiple times.
To temporarily enable such 'debug' repositories to install a
specific -debuginfo
package, use the option as
follows:
zypper --plus-content debug install "debuginfo(build-id)=eb844a5c20c70a59fc693cd1061f851fb7d046f4"
The build-id
string is reported by
gdb
for missing debuginfo packages.
To verify whether all dependencies are still fulfilled and to repair missing dependencies, use:
zypper verify
In addition to dependencies that must be fulfilled, some packages “recommend” other packages. These recommended packages are only installed if actually available and installable. In case recommended packages were made available after the recommending package has been installed (by adding additional packages or hardware), use the following command:
zypper install-new-recommends
This command is very useful after plugging in a webcam or Wi-Fi device. It will install drivers for the device and related software, if available. Drivers and related software are only installable if certain hardware dependencies are fulfilled.
There are three different ways to update software using Zypper: by
installing patches, by installing a new version of a package or by updating
the entire distribution. The latter is achieved with zypper
dist-upgrade
. Upgrading openSUSE Leap is discussed in
Book “Start-Up”, Chapter 12 “Upgrading the System and System Changes”.
To install all officially released patches applying to your system, run:
zypper patch
In this case, all patches available in your repositories are checked for relevance and installed, if necessary. After registering your openSUSE Leap installation, an official update repository containing such patches will be added to your system. The above command is all you need to enter to apply them when needed.
If a patch to be installed includes changes that require a system reboot, you will be warned before installing the patch.
Zypper knows three different commands to query for the availability of patches:
zypper patch-check
Lists the number of needed patches (patches, that apply to your system but are not yet installed)
tux >
sudo zypper patch-check
Loading repository data...
Reading installed packages...
5 patches needed (1 security patch)
zypper list-patches
Lists all needed patches (patches, that apply to your system but are not yet installed)
tux >
sudo zypper list-patches
Loading repository data...
Reading installed packages...
Repository | Name | Version | Category | Status | Summary
---------------+-------------+---------+----------+---------+---------
SLES12-Updates | SUSE-2014-8 | 1 | security | needed | openssl: Update to OpenSSL 1.0.1g
zypper patches
Lists all patches available for openSUSE Leap, regardless of whether they are already installed or apply to your installation.
It is also possible to list and install patches relevant to specific
issues. To list specific patches, use the zypper
list-patches
command with the following options:
--bugzilla[=number]
Lists all needed patches for Bugzilla issues. Optionally, you can specify a bug number if you only want to list patches for this specific bug.
--cve[=number]
Lists all needed patches for CVE (Common Vulnerabilities and Exposures) issues, or only patches matching a certain CVE number, if specified.
zypper list-patches --cve
Lists all 'needed' patches with a CVE number assigned.
zypper list-patches --all --cve Issue | No. | Patch | Category | Severity | Status ------+---------------+-------------------+-------------+-----------+---------- cve | CVE-2015-0287 | SUSE-SLE-Module.. | recommended | moderate | needed cve | CVE-2014-3566 | SUSE-SLE-SERVER.. | recommended | moderate | not needed [...]
Lists all patches with a CVE number assigned.
zypper list-patches --all --cve=CVE-2015-4477,CVE-2014-3639 Issue | No. | Patch | Category | Severity | Inter. | Status ------+---------------+----------+-------------+-----------+--------+----------- cve | CVE-2014-3639 | 2014-558 | security | moderate | reboot | not needed cve | CVE-2014-3639 | 2014-558 | security | moderate | reboot | not needed cve | CVE-2015-4477 | 2015-547 | security | important | --- | needed cve | CVE-2014-3639 | 3240 | recommended | moderate | --- | not needed cve | CVE-2014-3639 | 3240 | recommended | moderate | --- | not needed
Lists 'all' patches with CVE-2015-4477 or CVE-2014-3639.
To install a patch for a specific Bugzilla or CVE issue, use the following commands:
zypper patch --bugzilla=number
or
zypper patch --cve=number
For example, to install a security patch with the CVE number
CVE-2010-2713
, execute:
zypper patch --cve=CVE-2010-2713
If a repository contains only new packages, but does not provide
patches, zypper patch
does not show any
effect. To update all installed packages with newer available versions
(while maintaining system integrity), use:
zypper update
To update individual packages, specify the package with either the update or install command:
zypper update package_name zypper install package_name
A list of all new installable packages can be obtained with the command:
zypper list-updates
Note that this command only lists packages that match the following criteria:
has the same vendor like the already installed package,
is provided by repositories with at least the same priority than the already installed package,
is installable (all dependencies are satisfied).
A list of all new available packages (regardless whether installable or not) can be obtained with:
zypper list-updates --all
To find out why a new package cannot be installed, use the
zypper install
or zypper update
command as described above.
Whenever you remove a repository from zypper or upgrade your system, some packages can get in an “orphaned” state. These orphaned packages belong to no active repository anymore. The following command gives you a list of these:
zypper packages --orphaned
With this list, you can decide if a package is still needed or can be deinstalled safely.
When patching, updating or removing packages, there may be running
processes on the system which continue to use files having been deleted by
the update or removal. Use zypper ps
to show a list of
processes using deleted files. In case the process belongs to a known
service, the service name is listed, making it easy to restart the
service. By default zypper ps
shows a table:
PID | PPID | UID | User | Command | Service | Files ------+------+-----+-------+--------------+--------------+------------------- 814 | 1 | 481 | avahi | avahi-daemon | avahi-daemon | /lib64/ld-2.19.s-> | | | | | | /lib64/libdl-2.1-> | | | | | | /lib64/libpthrea-> | | | | | | /lib64/libc-2.19-> [...]
PID: ID of the process |
PPID: ID of the parent process |
UID: ID of the user running the process |
Login: Login name of the user running the process |
Command: Command used to executethe process |
Service: Service name (only if command is associated with a system service) |
Files: The list of the deleted files |
The output format of zypper ps
can be
controlled as follows:
zypper ps
-s
Create a short table not showing the deleted files.
PID | PPID | UID | User | Command | Service ------+------+------+---------+--------------+-------------- 814 | 1 | 481 | avahi | avahi-daemon | avahi-daemon 817 | 1 | 0 | root | irqbalance | irqbalance 1567 | 1 | 0 | root | sshd | sshd 1761 | 1 | 0 | root | master | postfix 1764 | 1761 | 51 | postfix | pickup | postfix 1765 | 1761 | 51 | postfix | qmgr | postfix 2031 | 2027 | 1000 | tux | bash |
zypper ps
-ss
Show only processes associated with a system service.
PID | PPID | UID | User | Command | Service ------+------+------+---------+--------------+-------------- 814 | 1 | 481 | avahi | avahi-daemon | avahi-daemon 817 | 1 | 0 | root | irqbalance | irqbalance 1567 | 1 | 0 | root | sshd | sshd 1761 | 1 | 0 | root | master | postfix 1764 | 1761 | 51 | postfix | pickup | postfix 1765 | 1761 | 51 | postfix | qmgr | postfix
zypper ps
-sss
Only show system services using deleted files.
avahi-daemon irqbalance postfix sshd
zypper ps
--print "systemctl status
%s"
Show the commands to retrieve status information for services which might need a restart.
systemctl status avahi-daemon systemctl status irqbalance systemctl status postfix systemctl status sshd
For more information about service handling refer to Chapter 10, The systemd
Daemon.
All installation or patch commands of Zypper rely on a list of known repositories. To list all repositories known to the system, use the command:
zypper repos
The result will look similar to the following output:
# | Alias | Name | Enabled | Refresh --+--------------+---------------+---------+-------- 1 | SLEHA-12-GEO | SLEHA-12-GEO | Yes | No 2 | SLEHA-12 | SLEHA-12 | Yes | No 3 | SLES12 | SLES12 | Yes | No
When specifying repositories in various commands, an alias, URI or
repository number from the zypper repos
command output
can be used. A repository alias is a short version of the repository name
for use in repository handling commands. Note that the repository numbers
can change after modifying the list of repositories. The alias will never
change by itself.
By default, details such as the URI or the priority of the repository are not displayed. Use the following command to list all details:
zypper repos -d
To add a repository, run
zypper addrepo URI alias
URI can either be an Internet repository, a network resource, a directory or a CD or DVD (see http://en.opensuse.org/openSUSE:Libzypp_URIs for details). The alias is a shorthand and unique identifier of the repository. You can freely choose it, with the only exception that it needs to be unique. Zypper will issue a warning if you specify an alias that is already in use.
If you want to remove a repository from the list, use the command
zypper removerepo
together with the alias or number
of the repository you want to delete. For example, to remove the
repository SLEHA-12-GEO
from
Example 2.1, “Zypper—List of Known Repositories”, use one of the following commands:
zypper removerepo 1 zypper removerepo "SLEHA-12-GEO"
Enable or disable repositories with zypper
modifyrepo
. You can also alter the repository's properties
(such as refreshing behavior, name or priority) with this command. The
following command will enable the repository named
updates
, turn on auto-refresh and set its priority to
20:
zypper modifyrepo -er -p 20 'updates'
Modifying repositories is not limited to a single repository—you can also operate on groups:
-a : all repositories |
-l : local repositories |
-t : remote repositories |
-m TYPE : repositories
of a certain type (where TYPE can be one of the
following: http , https , ftp ,
cd , dvd , dir , file ,
cifs , smb , nfs , hd ,
iso ) |
To rename a repository alias, use the renamerepo
command. The following example changes the alias from Mozilla
Firefox
to firefox
:
zypper renamerepo 'Mozilla Firefox' firefox
Zypper offers various methods to query repositories or packages. To get lists of all products, patterns, packages or patches available, use the following commands:
zypper products zypper patterns zypper packages zypper patches
To query all repositories for certain packages, use
search
. It works on package names, or, optionally, on
package summaries and descriptions. String wrapped in
/
are interpreted as regular expressions. By default,
the search is not case-sensitive.
fire
zypper search "fire"
MozillaFirefox
zypper search --match-exact "MozillaFirefox"
zypper search -d fire
zypper search -u fire
fir
not
followed be e
zypper se "/fir[^e]/"
To search for packages which provide a special capability, use the
command what-provides
. For example, if you want to
know which package provides the Perl module SVN::Core
,
use the following command:
zypper what-provides 'perl(SVN::Core)'
To query single packages, use info
with an exact
package name as an argument. It displays detailed information about a
package. To also show what is required/recommended by the package, use
the options --requires
and
--recommends
:
zypper info --requires MozillaFirefox
The what-provides package
is similar to rpm -q --whatprovides
package, but RPM is only able to query the RPM
database (that is the database of all installed packages). Zypper, on the
other hand, will tell you about providers of the capability from any
repository, not only those that are installed.
Zypper now comes with a configuration file, allowing you to permanently
change Zypper's behavior (either system-wide or user-specific). For
system-wide changes, edit /etc/zypp/zypper.conf
. For
user-specific changes, edit ~/.zypper.conf
. If
~/.zypper.conf
does not yet exist, you can use
/etc/zypp/zypper.conf
as a template: copy it to
~/.zypper.conf
and adjust it to your liking. Refer
to the comments in the file for help about the available options.
In case you have problems to access packages from configured repositories (for example, Zypper cannot find a certain package though you know that it exists in one the repositories), it can help to refresh the repositories with:
zypper refresh
If that does not help, try
zypper refresh -fdb
This forces a complete refresh and rebuild of the database, including a forced download of raw metadata.
If the Btrfs file system is used on the root partition and
snapper
is installed, Zypper automatically calls
snapper
(via script installed by
snapper
) when committing changes to the file system to
create appropriate file system snapshots. These snapshots can be used for
reverting any changes made by Zypper. See Chapter 3, System Recovery and Snapshot Management with Snapper
for more information.
For more information on managing software from the command line, enter
zypper help
, zypper help
command or refer to the
zypper(8)
man page. For a complete and detailed
command reference, including cheat sheets
with the
most important commands, and information on how to use Zypper in scripts
and applications, refer to
http://en.opensuse.org/SDB:Zypper_usage. A list of
software changes for the latest openSUSE Leap version can be found at
http://en.opensuse.org/openSUSE:Zypper versions.
RPM (RPM Package Manager) is used for managing software packages. Its main
commands are rpm
and rpmbuild
. The
powerful RPM database can be queried by the users, system administrators
and package builders for detailed information about the installed
software.
Essentially, rpm
has five modes: installing,
uninstalling (or updating) software packages, rebuilding the RPM database,
querying RPM bases or individual RPM archives, integrity checking of
packages and signing packages. rpmbuild
can be used to
build installable packages from pristine sources.
Installable RPM archives are packed in a special binary format. These
archives consist of the program files to install and certain meta
information used during the installation by rpm
to
configure the software package or stored in the RPM database for
documentation purposes. RPM archives normally have the extension
.rpm
.
For several packages, the components needed for software development
(libraries, headers, include files, etc.) have been put into separate
packages. These development packages are only needed if you want to
compile software yourself (for example, the most recent GNOME packages).
They can be identified by the name extension -devel
,
such as the packages alsa-devel
and gimp-devel
.
RPM packages have a GPG signature. To verify the signature of an RPM
package, use the command rpm --checksig
package-1.2.3.rpm to determine whether the
package originates from SUSE or from another trustworthy facility.
This is especially recommended for update packages from the Internet.
While fixing issues in the operating system, you might need to install a Problem Temporary Fix (PTF) into a production system. The packages provided by SUSE are signed against a special PTF key. However, in contrast to SUSE Linux Enterprise 11, this key is not imported by default on SUSE Linux Enterprise 12 systems. To manually import the key, use the following command:
rpm --import /usr/share/doc/packages/suse-build-key/suse_ptf_key.asc
After importing the key, you can install PTF packages on your system.
Normally, the installation of an RPM archive is quite simple:
rpm -i
package.rpm. With
this command the package is installed, but only if its dependencies are
fulfilled and if there are no conflicts with other packages. With an
error message, rpm
requests those packages that need
to be installed to meet dependency requirements. In the background, the
RPM database ensures that no conflicts arise—a specific file can
only belong to one package. By choosing different options, you can force
rpm
to ignore these defaults, but this is only for
experts. Otherwise, you risk compromising the integrity of the system and
possibly jeopardize the ability to update the system.
The options -U
or --upgrade
and
-F
or --freshen
can be used to update a
package (for example, rpm -F
package.rpm). This command removes the files
of the old version and immediately installs the new files. The difference
between the two versions is that -U
installs packages
that previously did not exist in the system, but -F
merely updates previously installed packages. When updating,
rpm
updates configuration files carefully using the
following strategy:
If a configuration file was not changed by the system administrator,
rpm
installs the new version of the appropriate
file. No action by the system administrator is required.
If a configuration file was changed by the system administrator before
the update, rpm
saves the changed file with the
extension .rpmorig
or
.rpmsave
(backup file) and installs the version
from the new package (but only if the originally installed file and the
newer version are different). If this is the case, compare the backup
file (.rpmorig
or .rpmsave
)
with the newly installed file and make your changes again in the new
file. Afterwards, be sure to delete all .rpmorig
and .rpmsave
files to avoid problems with future
updates.
.rpmnew
files appear if the configuration file
already exists and if the
noreplace
label was specified in the
.spec
file.
Following an update, .rpmsave
and
.rpmnew
files should be removed after comparing
them, so they do not obstruct future updates. The
.rpmorig
extension is assigned if the file has not
previously been recognized by the RPM database.
Otherwise, .rpmsave
is used. In other words,
.rpmorig
results from updating from a foreign format
to RPM. .rpmsave
results from updating from an older
RPM to a newer RPM. .rpmnew
does not disclose any
information to whether the system administrator has made any changes
to the configuration file. A list of these files is available in
/var/adm/rpmconfigcheck
. Some configuration files
(like /etc/httpd/httpd.conf
) are not overwritten to
allow continued operation.
The -U
switch is not just an
equivalent to uninstalling with the -e
option and
installing with the -i
option. Use -U
whenever possible.
To remove a package, enter rpm -e
package. This command only deletes the package
if there are no unresolved dependencies. It is theoretically impossible
to delete Tcl/Tk, for example, as long as another application requires
it. Even in this case, RPM calls for assistance from the database. If
such a deletion is, for whatever reason, impossible (even if
no additional dependencies exist), it may be helpful
to rebuild the RPM database using the option
--rebuilddb
.
Delta RPM packages contain the difference between an old and a new version of an RPM package. Applying a delta RPM onto an old RPM results in a completely new RPM. It is not necessary to have a copy of the old RPM because a delta RPM can also work with an installed RPM. The delta RPM packages are even smaller in size than patch RPMs, which is an advantage when transferring update packages over the Internet. The drawback is that update operations with delta RPMs involved consume considerably more CPU cycles than plain or patch RPMs.
The makedeltarpm
and applydelta
binaries are part of the delta RPM suite (package
deltarpm
) and help you create and apply delta
RPM packages. With the following commands, you can create a delta RPM
called new.delta.rpm
. The following command assumes
that old.rpm
and new.rpm
are
present:
makedeltarpm old.rpm new.rpm new.delta.rpm
Using applydeltarpm
, you can reconstruct the new RPM
from the file system if the old package is already installed:
applydeltarpm new.delta.rpm new.rpm
To derive it from the old RPM without accessing the file system, use the
-r
option:
applydeltarpm -r old.rpm new.delta.rpm new.rpm
See /usr/share/doc/packages/deltarpm/README
for
technical details.
With the -q
option rpm
initiates
queries, making it possible to inspect an RPM archive (by adding the
option -p
) and to query the RPM database of
installed packages. Several switches are available to specify the type of
information required. See Table 2.1, “The Most Important RPM Query Options”.
|
Package information |
|
File list |
|
Query the package that contains the file FILE (the full path must be specified with FILE) |
|
File list with status information (implies |
|
List only documentation files (implies |
|
List only configuration files (implies |
|
File list with complete details (to be used with
|
|
List features of the package that another package can request with
|
|
Capabilities the package requires |
|
Installation scripts (preinstall, postinstall, uninstall) |
For example, the command rpm -q -i wget
displays the
information shown in Example 2.2, “rpm -q -i wget
”.
rpm -q -i wget
#Name : wget Relocations: (not relocatable) Version : 1.11.4 Vendor: openSUSE Release : 1.70 Build Date: Sat 01 Aug 2009 09:49:48 CEST Install Date: Thu 06 Aug 2009 14:53:24 CEST Build Host: build18 Group : Productivity/Networking/Web/Utilities Source RPM: wget-1.11.4-1.70.src.rpm Size : 1525431 License: GPL v3 or later Signature : RSA/8, Sat 01 Aug 2009 09:50:04 CEST, Key ID b88b2fd43dbdc284 Packager : http://bugs.opensuse.org URL : http://www.gnu.org/software/wget/ Summary : A Tool for Mirroring FTP and HTTP Servers Description : Wget enables you to retrieve WWW documents or FTP files from a server. This can be done in script files or via the command line. [...]
The option -f
only works if you specify the complete
file name with its full path. Provide as many file names as desired. For
example, the following command
rpm -q -f /bin/rpm /usr/bin/wget
results in:
rpm-4.8.0-4.3.x86_64 wget-1.11.4-11.18.x86_64
If only part of the file name is known, use a shell script as shown in Example 2.3, “Script to Search for Packages”. Pass the partial file name to the script shown as a parameter when running it.
#! /bin/sh for i in $(rpm -q -a -l | grep $1); do echo "\"$i\" is in package:" rpm -q -f $i echo "" done
The command rpm -q --changelog
package displays a detailed list of change
information about a specific package, sorted by date.
With the help of the installed RPM database, verification checks can be
made. Initiate these with -V
, or
--verify
. With this option, rpm
shows
all files in a package that have been changed since installation.
rpm
uses eight character symbols to give some hints
about the following changes:
|
MD5 check sum |
|
File size |
|
Symbolic link |
|
Modification time |
|
Major and minor device numbers |
|
Owner |
|
Group |
|
Mode (permissions and file type) |
In the case of configuration files, the letter c
is
printed. For example, for changes to /etc/wgetrc
(wget
package):
rpm -V wget S.5....T c /etc/wgetrc
The files of the RPM database are placed in
/var/lib/rpm
. If the partition
/usr
has a size of 1 GB, this database can
occupy nearly 30 MB, especially after a complete update. If the
database is much larger than expected, it is useful to rebuild the
database with the option --rebuilddb
. Before doing this,
make a backup of the old database. The cron
script
cron.daily
makes daily copies of the database (packed
with gzip) and stores them in /var/adm/backup/rpmdb
.
The number of copies is controlled by the variable
MAX_RPMDB_BACKUPS
(default: 5
)
in /etc/sysconfig/backup
. The size of a single
backup is approximately 1 MB for 1 GB in
/usr
.
All source packages carry a .src.rpm
extension
(source RPM).
Source packages can be copied from the installation medium to the hard
disk and unpacked with YaST. They are not, however, marked as
installed ([i]
) in the package manager. This is
because the source packages are not entered in the RPM database. Only
installed operating system software is listed in
the RPM database. When you “install” a source package, only
the source code is added to the system.
The following directories must be available for rpm
and rpmbuild
in /usr/src/packages
(unless you specified custom settings in a file like
/etc/rpmrc
):
SOURCES
for the original sources (.tar.bz2
or
.tar.gz
files, etc.) and for
distribution-specific adjustments (mostly .diff
or .patch
files)
SPECS
for the .spec
files, similar to a meta Makefile,
which control the build process
BUILD
all the sources are unpacked, patched and compiled in this directory
RPMS
where the completed binary packages are stored
SRPMS
here are the source RPMs
When you install a source package with YaST, all the necessary
components are installed in /usr/src/packages
: the
sources and the adjustments in SOURCES
and the
relevant .spec
file in SPECS
.
Do not experiment with system components
(glibc
,
rpm
, etc.), because this
endangers the stability of your system.
The following example uses the wget.src.rpm
package.
After installing the source package, you should have files similar to
those in the following list:
/usr/src/packages/SOURCES/wget-1.11.4.tar.bz2 /usr/src/packages/SOURCES/wgetrc.patch /usr/src/packages/SPECS/wget.spec
rpmbuild -b
X
/usr/src/packages/SPECS/wget.spec starts the compilation.
X is a wild card for various stages of the
build process (see the output of --help
or the RPM
documentation for details). The following is merely a brief explanation:
-bp
Prepare sources in /usr/src/packages/BUILD
:
unpack and patch.
-bc
Do the same as -bp
, but with additional compilation.
-bi
Do the same as -bp
, but with additional installation
of the built software. Caution: if the package does not support the
BuildRoot feature, you might overwrite configuration files.
-bb
Do the same as -bi
, but with the additional creation
of the binary package. If the compile was successful, the binary
should be in /usr/src/packages/RPMS
.
-ba
Do the same as -bb
, but with the additional creation
of the source RPM. If the compilation was successful, the binary
should be in /usr/src/packages/SRPMS
.
--short-circuit
Skip some steps.
The binary RPM created can now be installed with rpm
-i
or, preferably, with rpm
-U
. Installation with rpm
makes it
appear in the RPM database.
The danger with many packages is that unwanted files are added to the
running system during the build process. To prevent this use
build
, which creates a defined environment in
which the package is built. To establish this chroot environment, the
build
script must be provided with a complete package
tree. This tree can be made available on the hard disk, via NFS, or from
DVD. Set the position with build --rpms
directory. Unlike rpm
, the
build
command looks for the .spec
file in the source directory. To build wget
(like in
the above example) with the DVD mounted in the system under
/media/dvd
, use the following commands as
root
:
cd /usr/src/packages/SOURCES/ mv ../SPECS/wget.spec . build --rpms /media/dvd/suse/ wget.spec
Subsequently, a minimum environment is established at
/var/tmp/build-root
. The package is built in this
environment. Upon completion, the resulting packages are located in
/var/tmp/build-root/usr/src/packages/RPMS
.
The build
script offers several additional
options. For example, cause the script to prefer your own RPMs, omit the
initialization of the build environment or limit the
rpm
command to one of the above-mentioned stages.
Access additional information with build
--help
and by reading the build
man
page.
Midnight Commander (mc
) can display the contents of
RPM archives and copy parts of them. It represents archives as virtual
file systems, offering all usual menu options of Midnight Commander.
Display the HEADER
with F3. View
the archive structure with the cursor keys and
Enter. Copy archive components with
F5.
A full-featured package manager is available as a YaST module. For details, see Book “Start-Up”, Chapter 9 “Installing or Removing Software”.