RPM (RedHat Package Manager) is the most popular package management utility for systems based on RedHat, such as RHEL, CentOS, Fedora... The tool allows system administrators and users to install, update, uninstall, query, check and manage system software packages on operating systems Unix / Linux... Package manager RPM stores information about the applications installed on the system in its database / var / lib / rpm... The .rpm files themselves contain the compiled versions of the software, the libraries necessary for their operation, as well as up-to-date information about package sources, versions and dependencies. RPM cannot manage software compiled and installed from source codes.

In fact RPM works in several modes. Requests and checks:

• rpm (-q | --query)
• rpm (-V | --verify)

Installing, updating, removing packages:

• rpm (-i | --install) PACKAGE_FILE ...
• rpm (-U | --upgrade) PACKAGE_FILE ...
• rpm (-F | --freshen) PACKAGE_FILE ...
• rpm (-e | --erase) [--allmatches] [--justdb] [--nodeps] [--noscripts] [- notriggers] [--test] PACKAGE_NAME ...

1. Check gpg package rpm signature

It is advisable to always check gpg Sign the package before installing it to verify its authenticity. # rpm --checksig pidgin-2.7.9-5.el6.2.i686.rpm pidgin-2.7.9-5.el6.2.i686.rpm: rsa sha1 (md5) pgp md5 OK

2. Installing the rpm package

To install the rpm package, use the key -i: # rpm -ivh pidgin-2.7.9-5.el6.2.i686.rpm Preparing ... ########################## ################## 1: pidgin ############################# ############# -i: Install package -v: show debug information -h: output hash marks on install

3. Check rpm package dependencies before installing

You can view the list of package dependencies like this: # rpm -qpR htop-2.0.2-2.fc26.aarch64.rpm ld-linux-aarch64.so.1 () (64bit) ld-linux-aarch64.so.1 (GLIBC_2. 17) (64bit) libc.so.6 () (64bit) libc.so.6 (GLIBC_2.17) (64bit) libm.so.6 () (64bit) libm.so.6 (GLIBC_2.17) (64bit ) libncursesw.so.6 () (64bit) libtinfo.so.6 () (64bit) rpmlib (CompressedFileNames)<= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 rtld(GNU_HASH) -q: execute request -p | --package: request information -R: query mode option, list of package dependencies

4.Rpm, installing packages without dependencies

If you are sure that all the necessary dependencies are installed, and rpm curses and does not allow installing the package, you can ignore the installation of dependencies using the flag --nodeps: # rpm -ivh --nodeps BitTorrent-5.2.2-1-Python2.4.noarch.rpm Preparing ... ####################### ##################### 1: BitTorrent ########################### ################ The above command will force the package to be installed despite errors rpm... Please note that if it turns out that the dependencies are still missing in the system, the installed program will not work and you will need to separately install the necessary dependencies.

5. Rpm, check the installed package

To check whether a package is installed or not, you need to request the required package: package htop installed # rpm -q htop htop-2.0.2-1.el7.x86_64 package fake not installed # rpm -q fake package fake is not installed

6.Rpm, list of installed package files

The list of files of the installed package can be obtained by request -ql (query list): # rpm -ql htop / usr / bin / htop /usr/share/doc/htop-2.0.2 /usr/share/doc/htop-2.0.2/AUTHORS /usr/share/doc/htop-2.0. 2 / COPYING /usr/share/doc/htop-2.0.2/ChangeLog /usr/share/doc/htop-2.0.2/README /usr/share/man/man1/htop.1.gz / usr / share / pixmaps / htop.png

7.Rpm, list of recently installed packages

# rpm -qa --last htop-2.0.2-1.el7.x86_64 Sat 03 Jun 2017 06:20:07 PM MSK

8. Rpm, list all installed packages

To get a list of all packages installed on the system, you need to run a query -qa without additional parameters # rpm -qa perl-HTML-Parser-3.71-4.el7.x86_64 dracut-network-033-463.el7.x86_64 filesystem-3.2-21.el7.x86_64 .......... ........... the list of packages will be quite large, for pagination you can use utilities such as more or less: # rpm -qa | more

9. Updating the rpm package

To update any rpm package option is used -U (upgrade). This option not only updates any package to the latest version, but also creates a backup copy of the old version of the package. If after the update something goes wrong and the software does not work, you can return to a previously installed and known working version. # rpm -Uvh nx-3.5.0-2.el6.centos.i686.rpm Preparing ... ########################### ################ 1: nx ############################## ############

10. Removing the rpm package

To remove a package, use the option -e (erase), the vv option is used for more verbose output of debug messages: # rpm -evv nx

11. Removing rpm package without dependencies

Parameter --nodeps forcibly removes a package rpm from the system. Be aware that removing a specific package may break other production applications. # rpm -ev --nodeps htop

12. Rpm, request a file belonging to a package

If you need to find out which package a particular file belongs to, use the option -qf (query file): # rpm -qf /etc/my.cnf mariadb-libs-5.5.52-1.el7.x86_64

13. Rpm, get information about an installed package

To get detailed information about the installed package, use the option -qi (query info): # rpm -qi htop Name: htop Version: 2.0.2 Release: 1.el7 Architecture: x86_64 Install Date: Sun 04 Jun 2017 10:20:51 AM MSK Group: Applications / System Size: 212139 License: GPL + Signature: RSA / SHA256, Sun 24 Jul 2016 09:22:13 PM MSK, Key ID 6a2faea2352c64e5 Source RPM: htop-2.0.2-1.el7.src.rpm Build Date: Sun 24 Jul 2016 01:01:34 PM MSK Build Host: buildvm-26.phx2.fedoraproject.org Relocations: (not relocatable) Packager: Fedora Project Vendor: Fedora Project URL: http://hisham.hm/htop/ Summary: Interactive process viewer Description: htop is an interactive text- mode process viewer for Linux, similar to top (1).

14.Rpm, get information about a package that is not yet installed

To get information about a package that has already been downloaded, but not yet installed, you can request -qip (query info package): rpm -qip ./pachage_name.rpm

15.Rpm, view documentation files for a specific package

Inquiry -qdf (query document file) will list all documentation files for the package: # rpm -qdf / usr / bin / htop /usr/share/doc/htop-2.0.2/AUTHORS /usr/share/doc/htop-2.0.2/COPYING / usr / share /doc/htop-2.0.2/ChangeLog /usr/share/doc/htop-2.0.2/README /usr/share/man/man1/htop.1.gz

16. Checking a specific rpm package

When checking a package, the information about the installed package files is compared with the database rpm... # rpm -Vp sqlbuddy-1.3.3-1.noarch.rpm S.5 .... T. c /etc/httpd/conf.d/sqlbuddy.conf

17. Checking all rpm packages

# rpm -Va S.5 .... T. c /etc/rc.d/rc.local ....... T. c /etc/dnsmasq.conf ....... T. /etc/ld.so.conf.d/kernel-2.6.32-279.5.2.el6.i686.conf

18. Import GPG key

To check packages RHEL / CentOS / Fedora, you need to import GPG key. To do this, run the following command: # rpm --import / etc / pki / rpm-gpg / RPM-GPG-KEY-CentOS-7

19.Rpm, view all imported keys

# rpm -qa gpg-pubkey * gpg-pubkey-7bd9bf62-5762b5f8 gpg-pubkey-352c64e5-52ae6884 gpg-pubkey-f4a80eb5-53a7ff4b gpg-pubkey-810f8996-552b1d92

20. Rebuild corrupted rpm database

Sometimes the rpm database can become corrupted and the rpm cannot function properly. If this happens, you need to rebuild the database. rpm: # cd / var / lib / rpm # rm -f __db. * # rpm --rebuilddb As usual: # man rpm Good luck

When a buyer tries to assemble a computer from components on his own or just choose a hard drive for a PC, he often comes across the concept of "RPM". What is it and is it important? RPM is not just important, but one of the key parameters of a hard disk that must be considered first of all when choosing. Let's take a closer look at what it is - RPM.

Concept

The abbreviation RPM (Rounds per minute) literally translates into Russian as "Revolutions per minute". This unit stands for a hard drive, but the concept itself does not say anything to the average user. The RPM of a hard disk plays a role in system performance, and the higher the rotational speed, the faster the entire system will run. Most often, this parameter is indicated in the characteristics of a hard drive, and it is advisable to choose the one with the higher RPM between the two hard drives.

If you take two disks that are identical in all parameters, but with different spindle speeds, you can immediately notice a significant difference in system performance.

What is a spindle?

The hard drive consists of several sealed round plates that are on top of each other and covered with a layer of ferromagnetic material. There is also a reading head in the housing. During operation, these plates rotate using a spindle - a special rotating shaft. This shaft is driven by an electric motor. When the plates rotate, the read heads do not touch the surface of the disks, but are at the closest possible distance to them. As a result, with the help of heads, you can write and read information from hard media - disks.

For thousands of hours, the spindle steadily rotates the plates at a tremendous speed, so this element must be reliable. Due to the absence of direct physical contact between the spindle and the disk, information can be written and erased on the latter. It is believed that on average one disc can be written and erased 100 thousand times.

This is what hard drive spindles look like. Of course, they may differ depending on the device model and manufacturer.

So, we found out that this is RPM. The parameter determines at what speed the plates can rotate during normal operation. In turn, this allows you to understand how quickly the computer system can receive information from the hard disk when accessing it. The higher the speed, the faster the data exchange between the system and the disk will take place.

How it works?

To understand more precisely what it is - RPM, it is necessary to understand the principle of operation of the device itself. When requesting certain information, the head unit jumps to the requested track. This takes a certain amount of time to search (Seek latency). After the read heads move to the desired sector, it is necessary to wait until the discs turn so that the desired area is under the read head. This time interval is called the spin delay. It is this parameter that depends on the spindle rotation speed, and the higher it is, the lower the rotation delay will be.

Both delays (for the movement of the spindle and for the rotation of the disks) determine the speed of the system's access to data. Many performance testing programs calculate this parameter and display it under the "Access to data time" lines. This allows you to determine the actual speed of the disk. This parameter directly affects the performance of the entire system. Today there are many powerful laptops that are equipped with powerful video cards and processors, and a lot of RAM. But at the same time, together with good hardware, very slow hard drives with a rotation speed of 5400 rpm are used. As a result, all these powerful components do not work at full capacity due to the slow speed of data access. So the RPM of the disk is important as well as the frequency of the processor and the width of the video card bus.

Impact of RPM HDD on performance

Winchesters (as hard drives are often called) can be LFF and SFF formats. To put it simply, one type of disc is 2.5 ", the other 3.5". The former is often used in laptops and servers, while the latter is used in conventional system units. It is this type of hard disk that is most often distinguished by a high spindle speed - 7200 rpm. In such models, the half-turn time is 4.2 ms, and the average search time is 8.5 ms. Therefore, the data access time will be 12.7 ms.

Note that most desktop computers use SATA hard drives. 7200 RPM is the standard speed for these models. There are also 5400 RPM discs, but they are not recommended for use on modern systems, although they are cheaper. There are also discs with a 10,000 RPM parameter - in such models, the search and rotation delays are about 3 ms. Such devices are most often used on gaming computers, but even they can be called outdated. Today's desktops and laptops are increasingly using SSDs, which work in a completely different way. We will talk about this a little later.

Custom RPM parameter

There are also models on the market with a spindle speed of 15,000 rpm. As you might have guessed, the latency times are even lower there - about 2ms, and the average seek time is 3.8ms. This allows access to data in 5.8 ms. Consequently, disks with a large RPM have a low search time for the required information, due to which a fast exchange between the information store and the system is ensured.

However, it is important to note that when accessing large data, the difference in performance between disks with large and low RPM parameters will be insignificant, since there will be no delays in accessing information at all.

How to find out the spindle speed?

Determining this parameter is as easy as shelling pears - it is always indicated on a sticker on the device itself. It is enough to open the case of your system unit and look at the sticker. There may be many incomprehensible parameters, but there is always one of the following lines:

1. RPM HDD: 5400.
2. RPM: 7200.
3. RPM: 10000.

If the hard drive is hidden under a laptop case, which is difficult enough to open, then you can use a special hardware testing program.

The following are popular:

1. Crystalmark.
2. Aida64.
3. Speccy.

They are available for download from the Internet for free. By running one of these programs, you can quickly find information about the storage device. The parameters of the hard disk will be displayed in detail. We are primarily interested in the "Rotation Rate" line and the value opposite it. In the Russian version of the Aida64 program, in the left part, click on "Data storage" - "Windows data storage", then in the upper part you need to select a hard disk, after which information about it will appear below, including the line "Rotation speed".

Disadvantages of high speed

Of course, a high RPM ensures high performance of the system as a whole, but there are also disadvantages. The faster the spindle rotates, the more the disk itself heats up, and it works noisier. Also, these hard drives consume more power. However, modern technology makes it possible to set the RPM and reduce energy consumption and noise by reducing the spindle speed. In this case, performance losses are compensated for by a special data caching algorithm.

SSD as an alternative

In the development of modern computer platforms, the use of hard disks with platters and a spindle is abandoned. Today, solid-state drives are used, in which there are no moving parts at all. The "insides" of these drives are the microcircuits on the board. Such devices work like ordinary flash drives, but the performance and speed of access to data in them is very high and far exceeds the performance of HDD standard disks. In addition, they are quiet, very light and consume little energy. The high price is the only drawback. 7200 RPM 1 TB will cost less than a 128 GB or 256 GB SSD.

By analogy, the difference between an SSD and an HDD is about the same as the difference between a regular DVD and a flash drive. They have already moved away from disks, and today only flash drives are mainly used.

Conclusion

When choosing a hard drive, it is first of all important to consider the performance parameter, which is determined by the spindle speed in the first place. Unfortunately, most users look at disk capacity, although this is not the most important thing. It is better to give preference to a hard drive with a capacity of 500 GB and a spindle speed of 7200 rpm than to choose a 1 TB disk with an RPM of 5400. In general, today you need to move away from using such systems, since SSD drives are superior to outdated HDD devices in everything ...

From Rosalab Wiki

This document aims to help people who want to release packages for the ROSA Desktop distribution. In particular, it highlights how ROSA packages differ from packages written for other RPM-based distributions. This document may be useful for ROSA developers as well as third party developers.

ROSA Desktop - a distribution of the GNU / Linux operating system - is produced and published by ROSA, by the efforts of various volunteers, testers, and translators.

Foreword

The reader is assumed to have experience with Linux. He should be familiar with the basic commands, the directory structure, and have already had to use rpm to at least install packages.

This document is structured to take the reader step by step to getting an rpm package that integrates well with ROSA Desktop.

As a first approximation, RPM denotes three concepts:

• a program for installing or creating packages;
• the format used in packages (binary or source) created by rpm;
• a file called a "package" containing binary or source code and an informational header. The title contains instructions for installing and uninstalling the program.

Rpm is, from a user perspective, a powerful package manager. She plays a role mediator for any action performed on rpm packages. In addition, she can:

• install or update a package, taking into account dependencies;
• during package installation, prepare actions to make the installed program ready for use;
• restore accidentally deleted files belonging to a package;
• show information that this package is already installed;
• find the package to which a certain file belongs;
• check the current installation to meet the dependency requirements of already installed packages;

From a programmer's point of view, an rpm program is a packer that hides in a single rpm file all the information needed to install a program on a given platform.

It is important to distinguish from the outset between .src.rpm source packages and binary packages (packages containing binary code). .rpm.

Installing the software

The basics

Although rpm was originally developed for the Red Hat Linux distribution, it also works on other rpm-based distributions: OpenMandriva, Suse, Fedora, etc .; rpm is already installed on all of these systems.

The rpm binary you build for ROSA may not work on other distributions.

Building packages for ROSA Desktop

Build packages for Cooker (i.e. the development version of ROSA Desktop) is always accompanied by patches and other improvements from the rpm side. Before starting the build, make sure that all of the following packages are installed on the system:

$ sudo urpmi rpm rpm-build spec-helper libtool rpmlint

• rpm - rpm itself;
• rpm-build - contains scripts used when building packages;
• spec-helper - a tool for minimizing spec files using some automation: parsing binary files, compressing manual pages (man pages);
• libtool - used by some configuration scripts to build shared libraries;
• rpmlint - used to validate the generated src.rpm file.

Preliminary tasks

Create required folders

Before you start building, you need to take care of the organization of the "workplace": the rpm program needs a certain directory tree in your "home" directory. This tree can be created using the following command: mkdir -p ~ / rpm / (BUILD, RPMS / $ ARCH, RPMS / noarch, SOURCES, SRPMS, SPECS, tmp).

Replace $ ARCH to the name of the architecture for which you plan to build. Usually this i586 or x86_64 but it can also be sparc, alpha or ppc.

Note
Assembly rpm-packages with superuser privileges can be dangerous because binaries are installed on the system before packaging, so you should always build packages with normal user privileges unless you want to accidentally clog the system.

The directory tree should have the following structure:

• ~ / rpm / BUILD: directory for the compiled sources.
• ~ / rpm / RPMS: contains directories, one directory for each architecture, where the binaries are put after building.
• ~ / rpm / RPMS / i586: directory for storing rpm packages for processors i586.
• ~ / rpm / RPMS / x86_64: directory for storing rpm packages for processors x86_64.
• ~ / rpm / RPMS / noarch: directory for storing rpm packages independent of processor architecture.
• ~ / rpm / SOURCES: source files (e.g. mypackage.tar.bz2).
• ~ / rpm / SPECS: The specs we need to build.
• ~ / rpm / SRPMS: compiled src.rpm-packages.
• ~ / rpm / tmp: for temporary files that rpm creates when building packages.

Note
program rpm directories are needed for different architectures in ~ / rpm / RPMS... If they are missing, you will receive an error message.

Don't create a .rpmmacros file

Several RPM building guides recommend creating an .rpmmacros configuration file in your home directory with personal information to be added to the package metadata, such as% packager values,% vendor, and others. Do not do that. All such fields are filled in automatically by the build system. However, you can still create this file if you want to specify a different build directory other than / home / user / rpm. In this case, specify values ​​only for% _topdir and% _tmppath macros. Do not provide values ​​for other macros.

Building RPM

From the existing "source" RPM

Building using existing sources is possible if the package is already in the distribution repositories.

The latest rpm file can be downloaded from Cooker. A list of Cooker mirrors is on the Cooker Mirror page. You can find there:

SRPMS Directory for storing rpm with "sources" ( main , contrib , non-free, etc.) for various processor architectures ( i586, x86_64, …); media / main For binary rpm from main ; media / contrib For binary rpm from contrib ; media / non-free For binary rpm from non-free ;

* "media / jpackage for binary rpm noarch. (jpackage no)

To change the source rpm for ROSA Linux, enter the command rpm -ivh my_package.src.rpm... This command will install all source files into the ~ / rpm directory you created.

Note
The program urpmi can be configured so that it downloads the "source" itself.

For example:

$ rpm -i /cooker/SRPMS/ktron-1.0.1-2mdv.src.rpm $ ls -R * SRPMS: SPECS: ktron.spec SOURCES: ktron-1.0.1.tar.bz2 RPMS: noarch / i686 / i586 / i386 / BUILD:

From the example above, you can see that rpm has installed the ktron-1.0.1.tar.bz2 source file and spec file into the rpm tree. It would be helpful to rebuild the current version of the package to understand how it compiles. To do this, you need to use the rpmbuild program by running it with the buildall option:

$ cd ~ / rpm / SPECS $ rpmbuild -ba ktron.spec $ ls -l ~ / rpm / RPMS / i586 / ktron-1.0.1-2mdv.i586.rpm $ ls -l ~ / rpm / SRPMS / ktron-1.0 .1-2mdv.src.rpm

If the build completed without errors (and, by the way, it can take several hours if a complex package is being built, for example, the kernel), the compiled package and the package with the source codes will be located in the ~ / rpm / RPMS / i586 and ~ / rpm / SRPMS / respectively. In order to install the compiled package, you need to obtain superuser rights. To do this, enter the su command in the terminal and enter the superuser password. To exit superuser mode, use the keyboard shortcut "Ctrl + D" or type the exit command. You do not need superuser privileges to build and rebuild source packages.

The build log can be quite large and can be saved for later review.

In the ~ / rpm / BUILD subdirectories, you can usually access the patched "sources" (if one or more patches were in the ~ / rpm / SOURCES directory), binaries, compiled libraries, manual pages, etc. The spec file describes the source code and patch files, how to build and install the package.

Now, to fix ktron, you just need to make changes to the spec file and then rebuild the package.

Note
Every package that ROSA Desktop builds uses the CVS version control system. This allows a record of each state of the package, that is, the developer can refer to the archive to view the changes made. If the changes made for any reason are not desirable, the developer can cancel them.

Each spec file is stored in the module SPECS / or contrib-SPECS / ... It can be accessed at cvs.mandriva.com.

Building from sources

Let's say you found an interesting program on the Freshmeat website or, and you want this program to be available to all ROSA Desktop users.

Download the source tarball and place it in the SOURCES directory.

Preliminary checks

License Despite the prevalence of the GPL, there are still many non-GPL licenses. It is necessary to accurately determine the license of the software in order to find out if it can be included in the distribution. We do not accept software using proprietary licenses, but there are a few exceptions for the club. Also, we cannot accept software that does not allow us to freely redistribute it. A list of licenses that are allowed for use in the distribution can be found on the Mandriva page. Compressing the tar archive We recommend using the original tar archive without any modifications. If the sources are distributed using different compression methods, we often prefer .tar.bz2. Avoid compressing patches (obtained by diff and other similar programs) and other text files (configuration files, scripts, etc.), as they usually take up very little space, otherwise it will be more difficult to see changes in Subversion diff files (Subversion itself uses some form of compression).

Note
For security-critical packages, we recommend that you do not change the source code, as this will lead to a change in the checksum and signature. We recommend leaving these packages in their original state, an example of such a package is OpenSSH.

Inside the spec file

So we got to one of the most important chapters of this document. The spec file contains all the information you need to:

• compiling the program, building the source code and the binary rpm package;
• installing and uninstalling the program.

In short, the spec file describes the simulated compilation and installation, tells rpm which files resulting from the installation should be packaged, and how they should eventually be installed on the system. Commands are executed using the shell / bin / sh, thus command constructs like [-f configure.in] && autoconf are correct and can be applied.

We will look at the main features used in one of the spec files. As you build more and more rpm packages, you will realize that there are some additional options that we haven't covered. For more information, see the Maximum RPM book (see section 7).

Consider the following example of a spec file taken from Cooker:

Name: gif2png Summary: Tools for converting websites from using GIFs to using PNGs Version: 2.0.1 Release: 1 Source0: http://www.tuxedo.org/~esr/gif2png/%(name)-%(version). tar.bz2 Source1:% (name) -% (version) -rosa-addon.tar.bz2 Patch0: gif2png-2.0.1-bugfix.patch URL: http://www.tuxedo.org/~esr/gif2png/ Group: Applications / Multimedia License: MIT-like Requires: python% description Tools for converting GIFs to PNGs. The program gif2png converts GIF files to PNG files. The Python script web2png converts an entire web tree, also patching HTML pages to keep IMG SRC references correct. % prep% setup -q -a 1% patch -p1% build% configure% make% install% makeinstall% files% defattr (0755, root, root)% doc README NEWS COPYING AUTHORS% (_ mandir) /man1/gif2png.1 *% (_ mandir) /man1/web2png.1*% (_ bindir) / gif2png% (_ bindir) / web2png # When preparing packages for ROSA, do not create the% changelog section yourself! % changelog * Mon Nov 02 1999 Camille Begnis 2.0.1-rosa2012 - Upgraded to 2.0.1 * Mon Oct 25 1999 Camille Begnis 2.0.0-rosa2012 - Specfile adaptations for Mandrake - add python requirement - gz to bz2 compression

The "%" at the beginning of a line can mean:

• the beginning of a section (section) ( prep, build, install, clean);
• inline shell script macro ( setup, patch);
• directive used by special sections (sections) ( defattr, doc, ...).

Header section ( header)

Name: gif2png Version: 2.0.1 Release: 1

These three lines automatically define constants that can be used in other sections of the spec file called% (name),% (version) and% (release). Some packages can build release using the deprecated% mkrel macro, which in ROSA distributions simply returns its argument.

In addition, there are a few tags that you might want to know about, but which are not in the sample spec file. There are some tags you might come across. Nobody requires you to remember all the tags if you are just starting to build rpm packages, but after a while, this list can serve as a good starting point!

Now is the time to explain how the package name is formed. It is very important to always follow this convention so that your work is clear to others.

• A binary package is denoted as follows: name-version-release.arch.rpm (name-version-release.arch.rpm)
• The source package is denoted as follows: name-version-release.src.rpm (name-version-release.src.rpm) (i.e., in our case, gif2png-2.0.1-1mdk.src.rpm)

The name is mostly chosen based on the name of the main binary package, although a different name can be used for good reason.

Version is the number in the name of the original source archive file: name-version.tar.gz.

A release is a number following the version, incremented with each new build of the package, which can be associated with the application of additional patches, changes made to the spec file, and even a trivial icon update.

Summary: tools for converting websites from using GIFs to using PNGs

This line is a description of the package.

Source0: http://www.tuxedo.org/~esr/gif2png/%(name)-%(version).tar.bz2

This line tells rpm which source file to use to build the package. Note that the filename is preceded by a full URL (which is generally optional) pointing to the website where the original source is located. rpm will strip the URL, keeping only the filename, and search the SOURCES directory. While providing the full URL is optional, its use is highly recommended so anyone can find out where to download the source.

If there are multiple source files, use multiple lines starting with Source1: ..., Source2: ... and so on, respectively.

Patch0: gif2png-2.0.1-bugfix.patch

This is an optional tag. It can be used in two cases:

1. You have fixed a bug in the source code of the program and created a patch that must be applied to the source code of the program before compilation.
2. You found out that there is a patch for this software package somewhere on the network, and you downloaded this patch.

All patches must be in the SOURCES directory. If there are several patches, then they should be named Patch1, Patch2 etc.

URL: http://www.tuxedo.org/~esr/gif2png/

This line points to the home page of the program. Its use is optional, but we still recommend specifying it.

Group: Multimedia

This snippet tells rpm where to place our package in the package tree. This feature is used by front-ends of package managers such as rpmdrake and kpackage.

The complete group structure, which by the way differs from similar Red Hat groups, can be found on the Packaging group page. It is very important to follow the accepted group conventions or your package will mess up the package tree.

License: MIT-like

This tag identifies the license chosen by the copyright holder that will apply to the software in the package. Most often it is the GPL. The ROSA license and licensing policy pages contain complete lists of licenses allowed for use.

BuildRequires: python

Indicates that compilation of rpm requires python libraries, it is often necessary to specify, for example, libpyglib-gi2, python-devel, if a package is not found immediately, then you can search for it using the command urpmi -p PackageName, since it can contained in another package, this is indicated by the command

Provides: libgif2png

Provides specifies the name of the library that can be used by other programs (provided)

Requires: python

This line was added because one of the programs included in the package is a script written in the Python programming language. This means that a python interpreter is required for the program to work correctly.

Minimum (or specific) version requirement can be used. For example:

Requires: python> = 1.5.1

In rare cases, an application may conflict with other already installed libraries or old versions of applications; in order to remove them from the system during installation, you need to inform the user about this, for this use the tag

Conflicts: python<= 1.0.0

Some packages become obsolete after installing new libraries, to mark them and remove the tag is used

Obsoletes: gif2png< 2.0.0

Below is the description tag:

% description Tools for converting GIFs to PNGs. The program gif2png converts GIF files to PNG files. The Python script web2png converts an entire web tree, also patching HTML pages to keep IMG SRC references correct.

This is a very special tag inside the heading part of the spec file, because it contains text that can span an arbitrary number of lines and paragraphs. The text contains a complete description of the software that helps the user decide whether to install a given package or not. In order to improve the perception of spec files, tag translations summary and description are stored in special files called Po.

% defattr (0755, root, root)

This tag sets the attributes that will be applied to all files copied to the user's system. Arguments mean:

• -: all attributes for regular files remain unchanged;
• root: the owner of the file is root;
• root: the file group is root;
• 0755: attributes applied to all directories belonging to the package - 0755 ( rwxr-xr-x).

% doc README NEWS COPYING AUTHORS

The special tag% doc marks files that are part of a package's documentation. Documentation files will be placed in /usr/share/doc/gif2png-2.0.1/. This directory will be created automatically. The% doc files are relative to the extracted tarball directory in the BUILD directory.

% (_ mandir) /man1/gif2png.1*% (_ mandir) /man1/web2png.1*

Also, you may be wondering: why is gif2png.1 * used instead of gif2png.1.lzma? This is done to maintain compatibility with other systems that use gzip compression instead of lzma. If you find such references to lzma compression in the spec, replace them with a regular expression, as in the example above. Most often you can use% (_ mandir) / man1 / *, which matches all files in the man1 directory.

% (_ bindir) / gif2png% (_ bindir) / web2png

As you can see, for each required path, there is a macro of the required type. The most useful ones are: (full list is available in / usr / lib / rpm / macros):% (_ prefix),% (_ bindir),% (_ sbindir),% (_ datadir),% (_ libdir),% (_ sysconfdir), % (_ mandir),% (_ infodir). For games use% (_ gamesbindir) and% (_ gamesdatadir).

Changelog section ( changelog)

Attention! Here is general information about the section changelog... You should not add this section to the spec file yourself, since it is generated automatically from the revision history in the version control system.

What are change logs

% changelog

This section is for keeping a record of the various changes made to the package. Each new build of the package must be accompanied by a paragraph in this section, as well as each new version number of the program. The following structure of these paragraphs is respected:

* Mon Nov 02 1999 Camille Begnis 2.0.1-1mdk

• the first line of a paragraph begins with an asterisk "*" and is separated from it by a space;
• three letters representing the day of the week;
• three letters representing the month;
• two digits of the day of the month;
• four digits of the year;
• the name of the person who created the package;
• his surname;
• his email address in angle brackets "<>»;
• current version and release.

- Upgraded to 2.0.1

This is followed by a single line beginning with "-" describing the change to the package.

Spec file stolen from korganizer. - last snapshot before release - ROSA adaptations. - Fix bug in / etc / zsh use USERNAME instead of USER. - Remove petit bouchon which annoys other players. - Improve / etc / z * to source the /etc/profile.d/ files. - fix typo in examples directory name - fixed QT libs version requirements - add patch to handle Earl Gray tea

By default, only records no older than 1 year are placed in the compiled package. This behavior can be changed by setting the% _changelog_truncate value

History of changes in the version control system

Information for the section changelog automatically generated from the revision history of the version control system. Each line of the message from the change history becomes an entry in the section changelog starting with a hyphen. Posts are automatically grouped by author name and email address.

If you do not want the line from the change history to go to the package changelog, add "SILENT:" at the beginning of the line. Blank lines are also ignored.

Assembly

Finally, our spec file is ready. Take a deep breath, sit down and type rpmbuild -ba mypackage.spec.

You can also add the --clean parameter, which will clear the BUILD directory after the package has finished building. This can be useful if you have little free space on your hard drive.

The process can end with the following results:

• exit 0;
• all other cases.

There are then two possibilities for the last line of your process:

• 0.01% probabilities: + exit 0
• 99.99% probabilities for other cases.

You are in the second case? Congratulations you passed the test, you are not an alien.

Good luck, so long, have a look to rpm building options (man rpmbuild) to debug your work, look at other persons "specfiles, etc ..

There is a very clean way to build packages: use rpmbuild -bs --rmspec --rmsource(in order to remove anything from the original build) and then do a rpmbuild --rebuild.

Optimizing the build process

When you run the command to build your package, you are sure to be led by a message like: foo-devel is necessary for foo2.

This means that you need information from other packages used for development (usually, such files are named like foo.h). If you don't have them, compilation will stop, or even if compilation succeeds, the package will be deprived of some features.

The ROSA Build Cluster has many of these pre-installed development packages ( devel-packages). If one of the required packages was not listed in the spec file, the package will be built on the cluster in any case. But the lack of such information will prevent building the package on machines that do not have a devel package, making debugging and updating more difficult.

Take a look at the website of the program you are preparing the package for for information on the required components.

To find these "missing BuildRequires" while building, only the most basic development packages should be present on the system:

• glibc-devel
• libncurses5-devel
• libstdc ++ 6-devel

After that, install only the developer packages requested by the rpm build team.

When starting the build, watch the messages checking for ...

If you see something like checking for foo ... foo.h not found, this means that the header file was not found on your system. Find a development package containing foo.h but be careful: you may find more than one package. So choose the one that suits you the most. For example, you should not select a network-related package if you are building an application designed to work with sound.

Then, install the package on the system, do not forget to add its name to the section BuildRequires your spec file.

Missing header files can be found at compile time. If it stops, check for other foo.hs and do the same.

Checking the RPM Package

Basic checks

First things first, you need to check the following:

• whether rpm's were created in the correct directories with the correct names (in the directories ~ / rpm / SRPMS / and ~ / rpm / RPMS / i586 /);
• is the information obtained with the command correct rpm -qlivp --changelog my_package. (src.) rpm.

Running Rpmlint

After that, you must use the Rpmlint utility, which will perform various checks on the package. Before running rpmlint, make sure you have the rpmlint-mandriva-policy package installed, which contains the validation rules for Dew. Dial rpmlint my_package. .rpm to get a report on a specific package. For more information, use the -i switch. You should check rpm and src.rpm. For more information on build errors, see the Build Issues page.

Install test

Now you need to check the installation and update of the package on any machine (preferably different from the one on which the build took place), and make sure that:

• All the necessary files have been created with the necessary rights and owners
• All scripts executed during the installation worked successfully
• All executables have the bit set executable, and the documentation files are available to all users

For completeness of testing, you can also check the process of removing the package, the functionality of the installed software, and the like.

If all tests are successful, then you are almost there - all that remains is to send the package to the repository.

Something went wrong?

If you are reading this document, then this is already good. If you do not find the answer to your question here, try also referring to the following sources:

1. Official document RPM-HOWTO(installed into the system along with the rpm program).
2. Red Hat Book Maximum RPM which is available at http://www.redhat.com/docs/books/max-rpm/max-rpm-html/.
3. look at the spec files of similar packages - perhaps their authors faced similar problems
4. Ask a question on the ROSA developer mailing list.

If you think that the solutions you find may be useful to others, please let the authors of the documents in which you would like to add descriptions of these solutions.

Pre-installation and post-installation scripts

The basics

An RPM package is more than just an archive of files that are extracted to specific directories on client systems.

The system provides programmers with a powerful feature: pre-installation and post-installation scripts. These scripts allow the package builder to write a piece of code that will run on the client machine when the package is installed or removed.

These scripts are created from any valid command line interpreter commands. Here are four of them:

There are some warnings regarding these scenarios. First, you must fit within the 8192 buffer size, and second, scripts must not be interactive. Anything that requires manual input from the user is invalid, as it breaks the non-interactive RPM installation procedures.

• % pre - This script is executed before the package is installed on the system.
• % post - This script is executed after the package is installed on the system.
• % preun - This script is executed before the package is removed from the system.
• % postun - This script is executed after the package is removed from the system.

The purpose of such scenarios can be extremely varied. The scripts must be designed in such a way that they do not harm the system. Remember that scripts are executed as the superuser. They are related to system administration tasks that complete the installation of a new application. For example:

• Add to cron running the program at regular intervals
• Run chkconfig to start the service at boot time

Working with updates

Working with packages is complicated by the fact that a package can be updated rather than simply installed or removed. the problem is that when updating, the% postun script of the new version of the package runs after the% post script of the old version, and what the last script did may be lost.

It is often useful to make sure that certain actions are performed only when installing / uninstalling a package, but not when updating. To handle such situations, RPM passes a special argument to the% pre,% preun,% post, and% postun scripts.

The argument contains the number of different versions of this package that will be installed on the machine after this script is executed. For example, when installing a new package, the% pre and% post scripts will be passed the value "1". When upgrading the package, the% pre and% post scripts of the new version will get the value "2", the scripts% preun and% postun of the old version - "1".

The presence of such a parameter allows programmers to distinguish in what situation the script is launched - during installation or when updating a package.

• For installation scripts (% post,% pre) - if the $ 1 parameter is "1", then the initial installation occurs
• For uninstallation scripts (% postun,% preun) - if the $ 1 parameter is "0", the package is removed; otherwise, it is an update or install with the --force option.

To check the value of a parameter, you can use the following construction:

% postun if [$ 1 -eq 0]; then ### Perform actions specific to package removal fi if [$ 1 -eq 1]; then ### Perform actions specific to the fi package upgrade

File triggers

ROSA uses RPM file triggers to eliminate the need to perform common tasks such as executing "% post -p / sbin / ldconfig" or "% update_menus".

More macros

When building packages for Dew, you can use various macros in the spec file to perform common tasks.

• Processing info pages:

% post% __ install_info% (name) .info% preun% __ install_info% (name) .info

• Menu system update. Rose uses the XDG Menu.

% post% (update_menus)% postun% (clean_menus)

• Processing localization files. It is a good practice not to manually list all the .mo files that are usually found in the / usr / share / locale / .. subdirectories, but to use a special macro in the% install section, which will create a separate file with a list of files with localizations:

% find_lang% (name)

The created file must be specified in the section files:

% files -f% (name) .lang

• The macros used during the build are% configure and% makeinstall. They automatically set the installation prefix as well as the various directories (such as bindir, datadir, and others). Typically, these macros work fine with small packages, but can be tweaking when building complex products. The% make macro invokes the make command with the appropriate -j option by parallelizing assembly on multicore machines. If you still need to call the script ./configure directly, never do not include the name of the target hardware architecture. For these purposes, there is a macro% ( target platform) (or even% ( target cpu) for more precise information).
• Assembly of server software. For a build that requires increased reliability at the expense of performance, we use a special macro% serverbuild, which must be called before starting the build itself. This macro sets the required values ​​of the optimization flags. The% build section will look like this:

% build% serverbuild% configure% make

• Macros for init scripts. When installing the package containing the init script (file in the /etc/init.d directory), you must register this script by calling chkconfig --add ..; when updating, you do not need to do this, but if the script works, then it must be restarted; when uninstalling a package, you need to remove the script information. For these purposes, we have a corresponding macro:

% post% _post_service % preun% _preun_service

• Treatment ghost-files. Some packages (in particular, many games) contain files that may not be present on the system at some point in time. Such files must be marked as ghost and process with special macros:

% install (...) mkdir -p% (buildroot) / var / lib / games touch% (buildroot) /var/lib/games/powermanga.hi% post% create_ghostfile /var/lib/games/powermanga.hi root games 664 (...)% files% attr (664, root, games)% ghost /var/lib/games/powermanga.hi

The% create_ghostfile macro will expand into the following construction:

If [! -f /var/lib/games/powermanga.hi]; then touch /var/lib/games/powermanga.hi chown root.games /var/lib/games/powermanga.hi chmod 664 /var/lib/games/powermanga.hi fi

• Bind .desktop / MIME file types to applications: The XDG menu system allows you to bind applications to files with a specified MIME type in .desktop files. When installing or uninstalling a .desktop file, you must run the utility update-desktop-database using the appropriate macros:

% post% update_desktop_database% postun% clean_desktop_database

• Freedesktop.org MIME Type Database: The database used to retrieve all possible MIME types with the corresponding file extensions or their magic numbers must be updated by calling the following macros:

% post% update_mime_database% postun% clean_mime_database

• Icon cache: all packages containing icons installed in / usr / share / icons / hicolor (or other directories provided by the freedesktop specifications, such as / usr / share / icons / gnome or / usr / share / icons / crystalsvg) must update the icon cache as shown in the following example (this requirement does not apply to icons stored in / usr / share / icons, / usr / share / icons / mini, or / usr / share / icons / large):

...% file ...% (_ iconsdir) / hicolor / *% (_ iconsdir) / crystalsvg / * ....% post% update_icon_cache hicolor% update_icon_cache crystalsvg% postun% update_icon_cache hicolor% update_icon_cache crystalsvg

• Registering GConf Schemas: GNOME GConf schemas should be installed and uninstalled using the following macros:

... # each schema key corresponds to a file named / etc / gconf / schemas / .schemas% define schemas apps_gnome_settings_daemon_default_editordesktop_gnome_font_rendering desktop_gnome_peripherals_keyboard_xkb fontilus themus% post% post_install_gconf_schemas% (schemas)% preun% preun_uninstall_gconf_schemas)

• Updating the scrollkeeper database: if the .omf file is installed, then the scrollkeeper database (used to index docbooks) needs to be updated:

...% post% update_scrollkeeper% postun% clean_scrollkeeper

Interaction with urpmi and rpmdrake

Sometimes it "s necessary to warn the user about some particular care that should be taken when upgrading or installing a specific version of a package. Rpmdrake-2.1.3-11mdk and above supports this: it searches in rpms for text files named README. install.urpmi, README.update.urpmi or README.urpmi, and displays them.

README.install.urpmi is displayed only for installed packages; README.update.urpmi only for upgraded packages; README.urpmi is displayed in both cases.

ROSA package groups

Each package must belong to one of the RPM groups used by ROSA.

Licenses

For questions regarding bundled software licenses, please refer to the Licensing policy.

Alternative: checkinstall

A very easy way to build RPMs for personal use is to install the checkinstall package; compile from source as usual (./configure && make && sudo make install), but just replace the make install step by checkinstall. This automates building an RPM, and is very simple to use. The advantage is that you don "t ever have to bypass the package manager when compiling from source. (However, it" s probably A Good Idea to build RPMs "properly" as described above, if you intend to distribute them to others.)

* .RPM - files similar to Windows SFX archives and installers.
As a rule, they contain the collected source codes of programs that are easy to edit.
The source code of the package itself is compiled with the extension .SRPM at the user's command.

Operations with packages from the console are performed by the RPM command.
I remind you:
help on it can be obtained by typing "rpm --help" or "rpm -?"; and the detailed manual is "man rpm"
(to exit the manual and return to the terminal, press "q").

Here it is suggested that you first familiarize yourself with the description of the programs themselves for installing packages
(the main one is rpm), and then - with a list of commands and parameters for this program.

Installing software in Linux.

There are three ways to install software on Linux:

• Traditional.
• From RPM packages.
• From packages containing source code.

Let's consider all three methods in order.

This method consists in the fact that the program is distributed not in assembled form, but in the form of source codes. This method is called traditional because it was the first method of installing programs before the advent of RPM or similar (apt-get).

1. The traditional way of installation is installation from sources.

Typically, the source code is distributed in an archive. Usually the file containing the source code has a double extension: for example, tar.gz or tar.bz2. This means that this file is compressed by two archivers: first tar, and then gzip.

You need to unpack the archive according to the stack principle: first with an external archiver, and then with an internal one. Let's assume prg-2.00.tar.gz is the filename of our archive. To unpack it, you need to enter the commands:

gunzip prg-2.00.tar.gz
tar xvf prg-2.00.tar

The first command will unpack the prg-2.00.tar file, which we will supply as one of the arguments in the second command. The x option to tar means we need to extract the files from the archive (the c option is create). You can specify the v parameter at your own discretion, it provides more information when the program is running.
The last parameter, f, is required when working with files.
The tar program was originally designed to work with tape streamers, so we need to use the f parameter to tell the program to work with files.
If the external extension is not gz, a bz or bz2, then instead of the first command you need to enter the commands (respectively):

bunzip prg-2.00.tar.bz
bunzip2 prg-2.00.tar.bz2

Then, as in the first case, you need to run the tar command (with the same parameters).

Sometimes source files have only one tgz extension. In this case, you only need to enter one command:

tar xzf prg-2.00.tgz

The z parameter means extract files using the gzunzip unpacker. Typically, archive files created with the tar program and passed through the gzip archiver filter have this extension.

The next stage is the direct installation of the program. After successfully completing the first stage (unpacking), change to the directory containing the sources. This is usually a directory<имя_программы-версия>:

cd prg-2.00

... / configure
make
make install

The first command configures the software being installed to work with your system. This program also checks if the program being installed can work on your system. If the program cannot work,
you will see a corresponding message and the installation process will be interrupted.

This usually happens when one of the libraries required by the new program is not installed on your system. To proceed with the installation, you need to install the required library and try to re-enter the. / Configure command. After the program finishes successfully. / Configure, a Makefile will be created, which will contain the necessary parameters (paths to libraries, path for installing the program) for the make program.

The second command (make) "builds" the program. At this stage, the program is compiled, that is, binary executable files are created from the sources.

The third command, make install, installs the program and the help files in the appropriate directories. Usually, programs are installed in the / usr / bin directory, but this depends on the contents of the Makefile.

After successful installation of the program, you can start it by first reading the documentation for this program.

2.Installing the program from the RPM package.

Software installation on Red Hat and Mandrake distributions is done using the rpm program. RPM (Red Hat Package Manager) is Red Hat's package manager. Despite the "Red Hat" in the name, it is entirely intended to function as an open source package system, available for anyone to use. It allows users to take the source code for new software and package it in source and binary form so that binaries can be easily installed and tracked and the source code easily
built. This system also maintains a database of all packages and their files, which can be used to inspect packages and request information about files and / or packages.

Unlike the familiar InstallShield wizards that are used to install Windows programs, RPMs (files with the .rpm extension) are not executable files, that is, programs. Packages contain files (like in an archive) that need to be installed, as well as various information about this package: which package is required for this package to work, which package it conflicts with, information about the developer, as well as information indicating what actions to take when installing this package, for example which directories to create. The RPM package manager is used in many Linux distributions (Red Hat, Mandrake, ASP, Black Cat) and is quite lightweight and flexible in use, which explains its popularity.

For example, for the software-1.0-I.i386.rpm package the following are the following: software - name;

1.0 - program version;
1 - package release;
i386 - Intel 386 platform.

Usually the name of the package file contains its name, version, release, platform. The last four characters - ".rpm" - an indication that this file is a package. In Linux, there is no such thing as an extension or file type.

Please note the difference between software version and package release. The version indicated in the package name is the version of the software that is in it. The version number is set by the author of the program, which is usually not the manufacturer of the package.
The version number identifies and refers to the software. As for the release number, it characterizes the package itself - it indicates the number of the existing version of the package. In some cases, even if the software has not changed, it may be necessary to repackage it.

With the name and version of the program, I think everything is clear. But the architecture is a little more complicated. The most "generic" packages are those for the Intel 386 architecture. This program should
run on any Intel processor starting with 80386DX (or compatible). However, if you have an 80486 processor, a package designed to work with the 80586 (Pentium) architecture will most likely not install on your system.
Typically, CISC (x86 instruction set) processors use the following conventions:

i386 - Intel 80368DX;
i586 - Intel Pentium (MMX), AMD K5 (K6);
i686 - Intel PPro, Celeron, PII, RSH, PIV.

In the simplest case, the package installation command looks like this:

rpm -i<пакет>

Before installing the program, RPM will check the package dependencies, that is, if you have any other packages installed on your system that are required or conflicting with the new program. If all the necessary
the program has packages (or the program does not need any additional packages at all), and if the new program does not conflict with any of the already installed packages, the RPM will install the program.
Otherwise, you will receive a message that the program requires some additional package or that the program conflicts with an already installed package.

If you need an additional package, just install it. But if the program conflicts with an already installed package, then you will need to choose which package you need more: already installed or new.

When installing the program, I recommend specifying two additional parameters: h and v. The first one tells the program to display the status bar of the installation process, and the second one displays additional messages. The status bar will be displayed as # symbols. Given these two parameters, the install command gets a little more complicated:

rpm -ihv software-1.0-1.i386.rpm

Installation can be performed not only from a local disk, but also via FTP:

To remove a package, use the command:

rpm -e<пакет>

Again, remember that when installing or removing packages, keep in mind that some packages may require other packages to be present on the system — this is called package dependencies. Therefore, sometimes you will not be able to install a particular package until you have installed all the packages that are required to make it work. When uninstalling a program, the package manager also checks the dependencies between the packages. If the package to be removed is needed by some other packages, you cannot remove it.

To skip checking dependencies, use the --nodeps option.
This is sometimes useful. For example, you have postfix installed and you need to install sendmail. Both programs are used to send mail.

However, many mail programs require an MTA (Mail Transfer Agent) - a program for sending mail (postfix or sendmail).
Therefore, you cannot uninstall the postfix program using the -e parameter.
You also cannot install the sendmail program without removing the postfix program, because the packages conflict with each other. In this case, the command will help you:

rpm -e -nodeps postfix

After such removal, normal operation of other programs that require MTA is not possible, so you need to immediately install the sendmail (or other MTA) program. In this case, you need to install the program, as usual, using the -i parameter.

The -U parameter is used to update programs. I recommend using it when installing programs, because if the package to be installed has already been installed, it will be updated, and if not, then the new package will simply be installed. To see a text indicator when installing packages, use the h option. The command to update the package:

rpm -Uhv<пакет>

For example:

rpm -Uhv software-1.1-4.i386.rpm

The text indicator will be displayed as # symbols. You can view all installed packages using the command:

rpm -qa I less

If you need to know if a specific package is installed, run the command:

rpm -qa | grep package_name

You can view general information about a package using the command:

rpm -qi package

and information about the files that are included in the package:

rpm -ql package

Gnorpm, kpackage, apt.

The RPM package manager is a powerful tool for performing operations on packages - create, install, update, remove. However, the command line interface may not appeal to everyone, especially a novice administrator. There are also graphical (for X Window) implementations of the package manager - for example, kpackage from KDE, gnorpm, and others.
I recommend using gnorpm, which has an intuitive graphical interface. RPM is more suitable for creating new packages, as well as updating a large number of packages. It is better and more convenient to use gnorpm to install one or two packages.

Functions of the gnorpm program:

Installing packages.
Removing packages.
Get information about a package.
Package check.
Search for a package in the RPM database.

To install any package, click the "Install" button. If there is an installation CD in the CD-ROM drive, then in the window that appears you will see a list of packages not yet installed on the system.

If the package is not in the list or you want to install a package that is not included in the distribution kit, click the Add button and add the packages you want to install to the list. Click on the "Request" button for package details.

If the package is not yet installed and you have enough disk space to install it, click the Install button. After that, the package will be checked to see if the dependencies are satisfied: does this package require the presence of some uninstalled package and does it conflict with already installed packages. If everything is in order, you will see the package installation status window.

You can find a package using the Search operation. To do this, click on the "Search" button on the gnorpm toolbar or execute the menu command Operations -> Search. In the window that opens, you can set the search criteria and click on the "Search" button.

KDE comes with a graphical user interface program for managing packages, kpackage. It is similar in function to the gnorpm program. Which of these programs to use is a matter of taste and habit.

Also worth mentioning is the APT program. APT is a software package management system. The APT system was originally developed for Debian Linux. Now included with some Red Hat compatible
distributions (for example, apt-get is included with AltLinux, but you won't find it on Red Hat Linux). The apt-get program is used to manage packages. The format for calling the apt-get program is as follows:

apt-get [options] [commands] [package. ... .]

The Linux Mandrake distribution includes its own package management tool, rpmdrake. By the tenth version of the distribution kit, it was slightly modified. It now has three parts:

/ usr / sbin / edit-urpm-media - package source manager (what sources are, I have already said, so we will not dwell on this);
rpmdrake - package installation manager;
rpmdrake-remove is a package removal manager.
You can start any of the parts from the K: System | Setting | Packages.

Install from packages containing source code.

Sometimes RPMs contain source code rather than compiled versions of programs. This is indicated by the word src instead of the name of the architecture. To install such a package, enter:

rpm --rebuild software-2.00-1.src.rpm

Of course, instead of software-2.00-l.src.rpm, you need to specify the real name of the file. Before installing the program, its source code will be compiled, and then the program will be installed.

GENERAL OPTIONS.

These options can be used in all modes of operation.

"-vv" Print a lot of debugging information.

"--quiet" Print as few messages as possible - as a rule, only error messages are output.

"--help" Print more detailed help on using rpm than usual.

"--version" Print one line containing the version number of the rpm you are using.

"--rcfile<список-файлов>" Each of the files from colon separated<списка-файлов>rpm is read sequentially for configuration information.
Default<список-файлов>looks like /usr/lib/rpm/rpmrc:/etc/rpmrc:~/.rpmrc.
Only the first line must exist in this list; all tildes will be replaced with the value of $ HOME.

"--root<каталог>"Use the file system rooted in<каталог>.
Note that this means that the database will also be read and modified under<каталог>, and all pre and post scripts will be executed after chroot () in<каталог>.

"--dbpath<путь>"Use the RPM database in<путь>.

"--justdb" Update only the database, not the file system.

"--ftpproxy , --httpproxy " Use as FTP or HTTP proxy.

"--ftpport<порт>, --httpport<порт>" Use<порт>as FTP or HTTP port of the proxy server.

"--pipe "Redirects rpm output to command input .

Database maintenance:

rpm -i [--initdb]

rpm -i [--rebuilddb]

DATABASE REBUILDING OPTIONS.

The general form of the command to rebuild the RPM database looks like this:
rpm --rebuilddb
To build a new database:
rpm --initdb
This mode only supports two options, --dbpath and --root.

Running
rpm --showrc
prints the values ​​that rpm will use for all options that can be set in rpmrc files.

Assembly:
rpm [-b | t] +
rpm [--rebuild] +
rpm [--tarbuild] +

PACKAGE ASSEMBLY (BUILDING) OPTIONS.

The general form of the command to build an rpm package looks like this:
rpm -O [build-options] +
The -bfR argument is used when a spec file is used to build the package. If rpmfR needs to extract this file from a gzip (or compress) archive, the -tfR argument is used. The first argument is followed by the next (OfR), which indicates which assembly and packaging steps should be performed. This is one of:

-bp Execute the% prep stage of the spec file. This usually involves unpacking the sources and applying patches to them.

"-bl" Do a "list check". In the "% files" section of the spec file, macros are expanded and the listed files are checked for existence.

"-bc" Execute the "% build" stage of the spec file (after doing the% prep stage). This usually boils down to running some equivalent of "make".

-bi Run the% install stage of the spec file (after doing the prep and build stages). This usually boils down to doing some kind of equivalent
"make install".

"-bb" Build a binary package (after doing the prep,% build and% install stages).

"-bs" Build only the source package (after doing the prep, build and install stages).

"-ba" Build the binary (RPM) and source (SRPM) packages (after doing the prep, build and install stages).

The following options can also be used:

"--short-circuit" Execute the specified stage directly, skipping the preceding ones. Can only be used with -bc and -bi.

"--timecheck" Set the age for the "timecheck" (0 to disable). This value can also be set by defining the "_timecheck" macro.
The timecheck value specifies the maximum age (in seconds) of files to be packed into the batch. A warning will be displayed for all files older than this age.

--clean Remove the build tree after the packages have been built.

"--rmsource" Remove sources and spec file after build (can be used separately, for example "rpm --rmsource foo.spec").

"--test" Do not run any build steps. Useful for testing spec files.

"--sign" Embed a PGP signature in the package. This signature can be used to verify the integrity and origin of a package. See section
PGP SIGNATURES for PGP options.

"--builroot<каталог>"Use directory<каталог>as the root for building packages.

"--target<платформа>" When building a package, interpret<платформа>as arch-vendor-os
and set the macros _target, _target_arch and _target_os accordingly.

"--buildarch "Build package for architecture oblivious to architecture
the system on which the assembly is performed. This option is deprecated; in RPM 3.0, the --target option should be used instead.

"--buildos "Build a package for the operating system not paying attention to
the architecture of the system on which the assembly is performed. This option is deprecated; in RPM 3.0, the --target option should be used instead.

RE-ASSEMBLY AND RECOMPILLATION OPTIONS.

There are two more ways to run rpm:

rpm --recompile<файл_исходного_пакета>+"

rpm --rebuild<файл_исходного_пакета>+"

When called in this manner, rpm installs the specified source package and runs% prep,% build, and% install. In addition, --rebuild builds a new binary package. After the build is complete, the tree used for the build is removed (as with the --clean option), the sources themselves, and the spec file.

SIGNATURE EXISTING RPM.

rpm --resign<файл_бинарного_пакета>+ This option generates and inserts new signatures into the specified packages.
All existing signatures from packages are removed.

rpm --addsign<файл_бинарного_пакета>+ This option generates and adds new signatures to the specified packages.
All existing package signatures are preserved.

PGP SIGNATURES.

In order to use the signing feature, rpm must be configured to run PGP and must be able to find the public key ring with the RPM key in it. By default rpm uses the PGP defaults to find keyrings (respecting PGPPATH).
If the key rings are not where PGP expects to find them, you must set up the "_pgp_path" macro to the directory containing the key rings.

If you want to be able to sign the packages you create, you also need to create your own public / private key pair (see the PGP documentation). Besides the aforementioned macro, you also need to configure macros

"_signature" Signature type. Currently only pgp is supported.

"_pgp_name" Username " whose keys you want to use to sign your packages.

When building packages, you add the --sign option to the command line. You will be asked for a password and your package will be built and signed.

For example, to use PGP to sign packages on behalf of the user "John Doe "from key rings located in /etc/rpm/.pgp, you must include

"% _signature"
pgp
"% _pgp_name"
/etc/rpm/.pgp
"% _pgp_name"
John doe "

Into the macro configuration file. Use / etc / rpm / macros for system-wide and ~ / .rpmmacros for custom configuration.

Serving installed packages:

rpm [--install] [install-options] [package-file] +
rpm [--eshen | -F] [install-options] [package-file] +
rpm [--uninstall | -e] [uninstall-options] [package] +
rpm [--verify | -V] [verification-options] [package] +

INSTALLATION AND UPDATE OPTIONS.

The general form of the rpm install command looks like this:
rpm -i [install-options]<файл_пакета>+
This command installs new packages.

The general form of the rpm update command looks like this:
rpm -U [install-options]<файл_пакета>+
This command updates the installed packages. This command works exactly the same as the installation command, except that all other package versions are removed from the system.

rpm [-F | --eshen] [install-options]<файл_пакета>+
Such a command updates packages, but only if earlier versions of these packages exist on the system.
Allowed task<файл_пакета>as ftp or http style URL. In this case, before installation, the file will be obtained from the server specified in the URL.

"--force" Same as the combination of --replacepkgs, --replacefiles, and --oldpackage.

"-h, --hash" Print 50 # characters as the package archive is unpacked. Used with -v for prettiness.

"--oldpackage" Allows you to replace a new package with an older one when upgrading (rollback).

"--percent" Print the percent ready as the package archive is unpacked. Designed to make it easier to use rpm from other utilities.

"--replacefiles" Install packages even if they overwrite files from other packages already installed.

"--replacepkgs" Install packages even if some are already installed on the system.

--allfiles Install or update all files identified as missingok, even if they already exist.

"--nodeps" Do not check dependencies before installing or upgrading a package.

"--noscripts" Do not execute pre- and post-installation scripts.

"--notriggers" Do not execute trigger scripts cocked to install this package.

"--ignoresize" Don't check the filesystem for enough free space before installing this package.

"--excludepath<путь>"Do not install files whose names start with<путь>.

"--excludedocs" Do not install any files marked as documentation files (includes manuals and texinfo docs).

"--includedocs" Install documentation files. This is the default behavior.

"--test" Don't install the package, just check if it can be installed and report possible problems.

"--ignorearch" Install or upgrade even if the architecture of the binary RPM and the machine does not match.

"--ignoreos" Install or upgrade even if the operating systems of the binary RPM and the machine do not match.

"--prefix<путь>"Set installation prefix to<путь>for relocatable packages.

"--relocate<старый_путь>=<новый_путь>" For relocatable packages: converts files that should have been installed in<старый_путь>v<новый_путь>.

--badreloc For use with --relocate. Moves even if the package is not relocatable.

"--noorder" Do not reorder the list of installed packages. Usually the list is reordered to satisfy dependencies.

Inquiry:
rpm [--query] [query-options]
rpm [--querytags]

REQUEST OPTIONS.

The general form of the rpm request (inspection) command looks like this:
rpm -q [request-options]
You can specify the format in which information about the package will be displayed. To do this, use the --queryformat option followed by a format string.

Query formats are a modified version of the standard printf (3) formatting. The format consists of static strings (which can include standard C escape sequences for newlines, tabs, and other special characters) and formats similar to those used in printf (3). Since rpm already knows the types of data to be printed, the type specifiers must be omitted and replaced with the names of header tags (keys) to be printed, enclosed in (). The RPMTAG_ tag name part can be omitted.

Alternative output formats can be specified by adding the: typetag tag to the name. The following types are currently supported: octal, date, shescape, perms, fflags, and depflags.

For example, to display only the names of requested packages, you can use% (NAME) as a format string. You can use% -30 (NAME)% (DISTRIBUTION) to display package names and distribution information in two columns.

When run with the --querytags argument, rpm will list all the tags it knows about.

There are two sets of options for the query - package selection and information selection.

Package selection options:

"<название_пакета>" Requesting an installed package called<название_пакета>.

"-a, --all" Query all installed packages.

"--whatrequires "Request for all packages requiring for proper functioning.

"--whatprovides "Request for all packages providing service.

"-f<файл>, --file<файл>" Request for the package that owns the file<файл>.

"-g<группа>, --group<группа>" Requesting packages from a group<группа>.

"-p<файл_пакета>"Requesting a (uninstalled) package<файл_пакета>.
File<файл_пакета>can be specified as ftp or http style URL; in this case, the package header will be received from the specified server.

"--specfile "Parsing and Query as if it were a package. Although not all information (such as file lists) is available, this type of request allows rpm to be used to extract information from spec files without having to write a spec file parser.

"--querybynumber "Request directly the database record number ... Useful for debugging purposes.

"--triggeredby<имя_пакета>" Query all packages that contain trigger scripts that are activated by the package<имя_пакета>.

Information selection options:

"-i"
Displays information about a package, including name, version, and description. Uses --queryformat if given.

"-R, --requires" List the packages this package depends on.

"--provides" List the services and libraries provided by this package.

"--changelog" Print the changelog for this package.

"-l, --list" List the files included in this package.

"-s, --state" List the status of files in the package (implies -l).

Each file can be in one of the following states: normal, not installed, or replaced.

"-d, --docfiles" List only documentation files (implies -l).

"-c, --configfiles" List only config files (implies -l).

"--scripts" Print package-specific scripts used as part of the installation / uninstallation process, if any.

"--triggers, --triggerscripts" Show all trigger scripts, if any, contained in the package.

"--dump" Print information about files as follows: path size mtime md5sum mode owner group isconfig isdoc rdev symlink.
This option must be used in conjunction with at least one of -l, -c, -d.

"--last" Sorts the list of packages by installation time so that the most recent packages are at the top of the list.

"--filesbypkg" Lists all files in each package.

"--triggerscripts" Shows all trigger scripts for the selected packages.

VERIFICATION OPTIONS.

The general form of the rpm verification command looks like this:
rpm -V | -y | --verify [verification-options]
During package verification, information about the installed files of the package is compared with information from the original package and from the RPM database. Verification checks the size, MD5 checksum, permissions, type, owner, and group of each file, among others. All inconsistencies are reported. The options for selecting packages are the same as for requesting (inspecting) packages.

Files that were not installed from the package (for example, documentation files that were excluded from the installation process with the "--excludedocs" option) are silently ignored.

Options that can be used in the verification process:

--nofiles Ignore missing files.

"--nomd5" Ignore MD5 checksum errors.
"--nopgp" Ignore PGP signing errors.

The output format is an eight character string, possibly "c" indicating a configuration file, and a filename. Each of the eight characters indicates the result of comparing one of the file attributes with the value recorded in the RPM database. The dot indicates that the test passed. The following symbols indicate errors in some tests:

"5" MD5 checksum.

"S" File size.

"L" Simlink.

"T" Modification time.

"D" Device.

"U" Master.

"G" Group.

"M" Permissions (includes permissions and file type).

SIGNATURE CHECK

The general form of the RPM signature verification command looks like this:
rpm --checksig<файл_с_пакетом>+
This command verifies the PGP signature embedded in the package to verify the integrity and origin of the package.
PGP configuration information is read from configuration files. See the PGP SIGNATURE section for more details.

REMOVAL OPTIONS (UNINSTALLATION)

The general form of the uninstall (uninstall) rpm command looks like this:
rpm -e<название_пакета>+

"--allmatches" Remove all package versions matching<название_пакета>Usually if<название_пакета>responds to multiple packets, is issued
error message and deletion is not performed.

"--noscripts" Do not execute pre- and post-installation scripts.

"--notriggers" Do not execute trigger scripts cocked to remove this package.

"--nodeps" Do not check dependencies before removing packages.

"--test" Don't delete, just pretend :) Useful in conjunction with the -vv option.

Miscellaneous:
rpm [--showrc]
rpm [--setperms] [package] +
rpm [--setgids] [package] +

FTP / HTTP OPTIONS.

rpm contains simple FTP and HTTP clients to make it easy to install and explore packages available over the Internet. Package files for installation,
updates and requests can be specified as ftp or http style url:
ftp: // :@hostname: /path/to/package.rpm
If part Omitted, the password will be prompted (once for each user / hostname pair). If neither nor Not specified, anonymous ftp will be used. In all cases, passive (PASV) FTP transfer is used.

Rpm allows the following options to be used with ftp URLs:

"--ftpproxy " System will be used as a proxy for all transfers, which allows FTP connections to be made through a firewall using a proxy to access the outside world. This option can also be set by setting the _ftpproxy macro.

"--ftpport "Specifies the TCP port number used for FTP connections instead of the default port.
This option can also be set by setting the _ftpport macro.

Rpm allows the following options to be used with http URLs:

"--httpproxy " System will be used as a proxy for all forwarding, which allows HTTP connections to be made through a firewall that uses a proxy to access the outside world. This option can also be set by setting the _httpproxy macro.

"--httpport "Specifies the TCP port number used for HTTP connections instead of the default port.
This option can also be set by setting the _httpport macro.

Prepared by Dvoe4nik85