edgecase
Rather than assume people are too damaged to interpret reality, the default assumption should be: all of this is a defense against change.
~ The Last Psychiatrist
Author: StJohn Piano
Published: 2018-04-19
Datafeed Article 48
This article has been digitally signed by Edgecase Datafeed.
51606 words - 15080 lines - 377 pages



GOAL



Without using a network connection, install a C compiler on Kalkin, which is running Centos 6.9 Minimal.





CONTENTS



- Goal
- Contents
- Brief Summary
- Representative Sample Of Bash Commands Used
- Downloadable Assets
- Discoveries
- Thoughts
- Project Log




BRIEF SUMMARY



I installed a package containing GCC, which can be used to compile C, along with eight additional packages that provided necessary dependencies.

I learned how to use the RPM Package Manager (included with Centos 6.9 Minimal) to install rpm packages on Centos 6.9 Minimal on Kalkin. I also learned how to find out which dependencies were missing and how to obtain the rpm packages that provided them.

I used
rpm
to check the validity of the digital signatures in each package. All of them were signed by the Centos 6 signing key.

I was able to successfully compile and run a Hello World C program.

I learned a fair amount about:
- CentOS
- OpenPGP Keys
- Unix
- Recording Shell Output
- Yum
See Discoveries section.

I learned a lot about:
- RPM
See Discoveries section.

I now have a much better understanding of the problems of package management in general.
See Thoughts section.






REPRESENTATIVE SAMPLE OF BASH COMMANDS USED



aineko:Downloads stjohnpiano$ grep gcc available_tools_on_centos_69_minimal.txt


[root@kalkin ~]# blkid


[root@kalkin ~]# ls -1 /mnt/test1


[root@kalkin work]# mount /dev/sdg1 /mnt/test1


[root@kalkin ~]# mkdir /home/work/rpms


[root@kalkin ~]# ls /home/work/rpms


[root@kalkin work]# script screen.log


[root@kalkin work]# cp screen.log /mnt/test1/


[root@kalkin work]# umount /mnt/test1/


aineko:Downloads stjohnpiano$ wc -c screen.log


aineko:Downloads stjohnpiano$ tr -cd "\r" < screen.log | wc -c


aineko:Downloads stjohnpiano$ tr -d "\r" < screen.log | wc -c


aineko:Downloads stjohnpiano$ tr -d "\r" < screen.log > screen2.log


[root@kalkin work]# ls -1 /etc/yum*


[root@kalkin work]# cp -r /etc/yum.repos.d /mnt/test1/


aineko:HP v150w stjohnpiano$ cat yum.repos.d/CentOS-Base.repo


[root@kalkin work]# echo -e "\n\nCOMMAND# rpm --version\n" | tee -a work.log


[root@kalkin work]# rpm --version | tee -a work.log


[root@kalkin work]# ls -1a ~


[root@kalkin work]# ls -1a ~/.gnupg


[root@kalkin work]# gpg /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6


[root@kalkin work]# gpg --with-fingerprint --keyid-format long /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6


[root@kalkin work]# gpg --list-packets /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm


[root@kalkin work]# rpm --query --info --package rpms/gcc-4.4.7-18.el6.x86_64.rpm


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --configfiles


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --docfiles


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --dump


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --list


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --filesbypkg


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --scripts


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --conflicts


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --provides


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --requires


aineko:Downloads stjohnpiano$ head -1 dump.txt


aineko:Downloads stjohnpiano$ cat dump.txt | sed 's/ .*//' > dump2.txt


aineko:Downloads stjohnpiano$ diff list.txt dump2.txt


aineko:Downloads stjohnpiano$ head -1 filesbypkg.txt | awk '{print $2}'


aineko:Downloads stjohnpiano$ cat filesbypkg.txt | awk '{print $2}' > filesbypkg2.txt


[root@kalkin work]# which install-info


[root@kalkin work]# rpm --query --file /sbin/install-info

info-4.13a-8.el6.x86_64

[root@kalkin work]# rpm --query rpm


[root@kalkin work]# rpm --query rpm --list


[root@kalkin work]# cp /usr/share/man/man8/rpm.8.gz rpm.8.gz


[root@kalkin work]# gunzip rpm.8.gz


[root@kalkin work]# file rpm.8


[root@kalkin work]# rpm --query --whatprovides /bin/sh


[root@kalkin work]# rpm --query --whatprovides libc.so.6\(\)\(64bit\)


[root@kalkin work]# rpm --query --whatprovides libgcc


[root@kalkin ~]# rpm --showrc


[root@kalkin ~]# rpm --query --all | grep xz


[root@kalkin work]# rpm --verify --all


[root@kalkin work]# rpm --query --all | while read line ; do rpm --query --info $line > results/$line.info; done


[root@kalkin work]# du -h


[root@kalkin work]# mv results 20180329_kalkin_rpm_package_info_and_dumps


[root@kalkin work]# tar -zcf 20180329_kalkin_rpm_package_info_and_dumps.tar.gz 20180329_kalkin_rpm_package_info_and_dumps


[root@kalkin work]# du -h 20180329_kalkin_rpm_package_info_and_dumps.tar.gz


[root@kalkin work]# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6


[root@kalkin work]# rpm --checksig rpms/gcc-4.4.7-18.el6.x86_64.rpm


[root@kalkin work]# rpm --checksig rpms/gcc-4.4.7-18.el6.x86_64.rpm --verbose


[root@kalkin work]# rpm --install --test rpms/gcc-4.4.7-18.el6.x86_64.rpm


[root@kalkin work]# rpm --install rpms/cloog-ppl-0.15.7-1.2.el6.x86_64.rpm --test


rpm --install rpms/cloog-ppl-0.15.7-1.2.el6.x86_64.rpm --test 2>&1 | tee -a work.log


[root@kalkin rpms]# rpm --install gcc-4.4.7-18.el6.x86_64.rpm cloog-ppl-0.15.7-1.2.el6.x86_64.rpm cpp-4.4.7-18.el6.x86_64.rpm glibc-devel-2.12-1.209.el6.x86_64.rpm glibc-headers-2.12-1.209.el6.x86_64.rpm kernel-headers-2.6.32-696.el6.x86_64.rpm libgomp-4.4.7-18.el6.x86_64.rpm mpfr-2.4.1-6.el6.x86_64.rpm ppl-0.10.2-11.el6.x86_64.rpm --verbose


[root@kalkin rpms]# rpm --query --all | wc -l


[root@kalkin rpms]# rpm --query --all | sort


[root@kalkin work]# gcc hello_world.c


[root@kalkin work]# gcc -o hello_world hello_world.c


[root@kalkin work]# ./hello_world






DOWNLOADABLE ASSETS



The Centos 6 signing key:

rpm-gpg-key-centos-6


The list of available Bash tools on Centos 6.9 Minimal:

available_tools_on_centos_69_minimal.txt


The list of rpm packages included with Centos 6.9 Minimal:

centos_69_minimal_package_list.txt


The new list of rpm packages installed on Centos 6.9 Minimal running on Kalkin. This includes:
- the rpm package for gcc
- the rpm packages for gcc's dependencies
- the rpm package containing the imported Centos 6 signing key:

centos_69_minimal_new_package_list.txt


The results of running
rpm --query [package_name] --info
and
rpm --query [package_name] --dump
for each installed rpm package (before any new packages were installed):

20180329_kalkin_rpm_package_info_and_dumps.tar.gz


The results of running
rpm --query [package_name] --provides
for each installed rpm package (before any new packages were installed):

20180401_rpm_package_provides.tar.gz


The package for gcc:

gcc-4.4.7-18.el6.x86_64.rpm


The packages for the dependencies of gcc:

cloog-ppl-0.15.7-1.2.el6.x86_64.rpm
cpp-4.4.7-18.el6.x86_64.rpm
glibc-devel-2.12-1.209.el6.x86_64.rpm
glibc-headers-2.12-1.209.el6.x86_64.rpm
kernel-headers-2.6.32-696.el6.x86_64.rpm
libgomp-4.4.7-18.el6.x86_64.rpm
mpfr-2.4.1-6.el6.x86_64.rpm
ppl-0.10.2-11.el6.x86_64.rpm


The man page for rpm, which is part of the rpm package, and was found (zipped) on Kalkin at location:
/usr/share/man/man8/rpm.8.gz

File type: troff or preprocessor input text
rpm.8


Hello World in C:
hello_world.c



Note: I have changed all asset names to be lower case. This affects RPM-GPG-KEY-CentOS-6.


Note: This recipe builds on top of Centos 6.9 Minimal. The file containing this operating system (centos-6.9-x86_64-minimal.iso) is stored as an asset of this article:
Installing Centos 6.9 Minimal on Kalkin





DISCOVERIES



Subsections:
- 1) Architectures
- 2) Acronyms
- 3) CentOS
- 4) OpenPGP Keys
- 5) Unix
- 6) Recording Shell Output
- 7) Yum
- 8) RPM
- 9) RPM - Further Details



1) ARCHITECTURES

- i686 code is intended to be executed on processors which are compatible with the Intel x86 32-bit platform.

- x86_64 code is intended to be executed on processors which are compatible with the AMD64 64-bit platform.

- A 32-bit OS can be installed on a 64-bit platform.

- Many 32-bit apps can be run on a 64-bit OS.



2) ACRONYMS

- RHEL == Red Hat Enterprise Linux

- EL5 == Enterprise Linux 5 (either Red Hat Enterprise Linux or CentOS)

- EL6 == Enterprise Linux 6

- RPM == Red Hat Package Manager

- RPM originally stood for "Red Hat Package Manager" but has now become a recursive acronym for "RPM Package Manager".

- MPI == multi-precision-integer

- "an rpm" can be used to refer to a single package, usually named packagename-version.arch.rpm.

- EPEL == Extra Packages for Enterprise Linux
-- Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS, Scientific Linux (SL), and Oracle Linux (OL).



3) CENTOS

Centos 6.9 Minimal includes these keys, stored in the directory
/etc/pki/rpm-gpg/
.
- RPM-GPG-KEY-CentOS-6
- RPM-GPG-KEY-CentOS-Debug-6
- RPM-GPG-KEY-CentOS-Security-6
- RPM-GPG-KEY-CentOS-Testing-6

I downloaded and installed 9 packages comprising GCC and its dependencies. All the packages were signed by RPM-GPG-KEY-CentOS-6.

RPM-GPG-KEY-CentOS-6 is a V4 key, but was used to generate V3 digital signatures for the packages I used in this project, probably for compatibility with older combinations of rpm and gpg, which expect V3 keys and signatures.

Before installing gcc, I found that there were 31491 files in the RPM database.
[root@kalkin work]# rpm --query --all --filesbypkg | wc -l

31491



DEPENDENCY TREE FOR THE GCC PACKAGE:

Base dependency: The operating system image
- centos-6.9-x86_64-minimal.iso

Goal dependency: The gcc compiler package
- gcc-4.4.7-18.el6.x86_64.rpm

Tree of missing dependencies:
- gcc-4.4.7-18.el6.x86_64.rpm
-- cloog-ppl-0.15.7-1.2.el6.x86_64.rpm
--- ppl-0.10.2-11.el6.x86_64.rpm
-- cpp-4.4.7-18.el6.x86_64.rpm
--- mpfr-2.4.1-6.el6.x86_64.rpm
-- glibc-devel-2.12-1.209.el6.x86_64.rpm
--- glibc-headers-2.12-1.209.el6.x86_64.rpm
---- kernel-headers-2.6.32-696.el6.x86_64.rpm
-- libgomp-4.4.7-18.el6.x86_64.rpm


DEPENDENCY TREE IN RECURSIVE LIST FORMAT:

Base: centos-6.9-x86_64-minimal.iso

Level 1:

gcc-4.4.7-18.el6.x86_64.rpm requires:
- cloog-ppl-0.15.7-1.2.el6.x86_64.rpm
- cpp-4.4.7-18.el6.x86_64.rpm
- glibc-devel-2.12-1.209.el6.x86_64.rpm
- libgomp-4.4.7-18.el6.x86_64.rpm

Level 2:

cloog-ppl-0.15.7-1.2.el6.x86_64.rpm requires:
- ppl-0.10.2-11.el6.x86_64.rpm

cpp-4.4.7-18.el6.x86_64.rpm requires:
- mpfr-2.4.1-6.el6.x86_64.rpm

glibc-devel-2.12-1.209.el6.x86_64.rpm requires:
- glibc-headers-2.12-1.209.el6.x86_64.rpm

Level 3:

glibc-headers-2.12-1.209.el6.x86_64.rpm requires:
- kernel-headers-2.6.32-696.el6.x86_64.rpm



4) OPENPGP KEYS

Key formats:
- There are two versions of key-material packets. Version 3 packets were first generated by PGP 2.6. Version 4 keys first appeared in PGP 5.0 and are the preferred key version for OpenPGP.
- V3 == Version 3
- V4 == Version 4
- V3 keys are deprecated.
- The key ID of a V3 key is the last section of its public modulus.
- The fingerprint of a V3 key is the last section of a hash of several pieces of information, one of which is the key.
- The fingerprint of a V4 key is the last section of a hash of several pieces of information, one of which is the key.
- The key ID of a V4 key is the last section of its fingerprint.
- If V3 and V4 format keys share the same RSA key material, they will have different fingerprints and different Key IDs.
- An implementation of RFC 4880 (e.g. GPG) should only create V4 keys. It may accept V3 keys.
- Older combinations of rpm and gpg expect V3 keys and signatures.
- For V4 keys, the short key ID is the last half of the long key ID.

Key IDs:
- Key IDs are short "names" for keys, shorter than the fingerprint or the modulus. They are used for convenience, as less typing/reading is required and they are more human-intelligible. However, they are less secure, because another key with the same key ID can be generated (on purpose or by accident).
- A short key ID, e.g. A4FF 2279, is 8 hex characters. Each pair of hex characters represents one octet (8 bits), so the short key ID consists of 4 octets (32 bits).
- A long key ID, e.g. 4E1F 799A A4FF 2279, is 16 hex characters. It therefore consists of 8 octets (64 bits).
- GPG has trouble handling two keys that have the same key ID.

The short key ID can be viewed by running:

gpg /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6


The long key ID and the fingerprint of a key can be viewed by running:

gpg --with-fingerprint --keyid-format long /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6


User IDs:
- A user ID is some text that is a human-readable identifier for a key's user.
Example: Heinrich Heine <heinrichh@duesseldorf.de>
It is of course easily forged (someone else can simply create a key or a message with the same user ID text). Digital signatures should be used to prove that a user ID is attached to a particular key/message.



5) UNIX

- Unix regards everything as a file.

- Files can be divided into three categories; ordinary or plain files, directories, and special or device files.

- Directories in Unix are properly known as directory files. They contain information such as owner, permissions, and size for a set of files.

- Ordinary or plain files may contain ASCII text, binary data, and program input or output. Executable binaries (programs) are also ordinary files, as are commands. When a user enters a command, the associated file is retrieved and executed.

- Special files are also known as device files. In Unix all physical devices are accessed via device files; they are what programs use to communicate with hardware. Files hold information on location, type, and access mode for a specific device.

- There are two types of device files: character and block, as well as two modes of access.
-- Block device files are used to access block device I/O. Block devices do buffered I/O, meaning that the the data is collected in a buffer until a full block can be transfered.
-- Character device files are associated with character or raw device access. They are used for unbuffered data transfers to and from a device. Rather than transferring data in blocks the data is transfered character by character. One transfer can consist of multiple characters.

- Device files are found in the /dev directory. Each device is assigned a major and minor device number. The major device number identifies the type of device, i.e. all SCSI devices would have the same number as would all the keyboards. The minor device number identifies a specific device, i.e. the keyboard attached to this workstation.

- The major and minor device numbers are indexed to device switches. There are two types of device switches: cdevsw for character devices and bdevsw for block devices. These switches are kernel structures that hold the names of all the control routines for a device and tell the kernel which driver module to execute.



6) RECORDING SHELL OUTPUT

Use the
tee
command.

Example:
program [arguments...] 2>&1 | tee -a outfile


This should display both output and error messages and append these to a storage file.

The -a option means "append".

2>&1
can be used in Bash to redirect errors/warnings (which are normally sent to stderr) to normal output (stdout). In this case both will be piped to the next command (
tee
).

Note:
tee
doesn't record the command itself, only the output. This can be worked around by echoing the command to the log file before running it. Use the
-e
flag for the
echo
command so that it will interpret backslash-escaped newline characters.

[root@kalkin work]# echo -e "\n\nCOMMAND# rpm --version\n" | tee -a work.log


[root@kalkin work]# rpm --version | tee -a work.log


[root@kalkin work]# echo -e "\n\nCOMMAND# rpm --help\n" | tee -a work.log


[root@kalkin work]# rpm --help | tee -a work.log



Example of capturing output sent to standard error:

# rpm --install rpms/cloog-ppl-0.15.7-1.2.el6.x86_64.rpm --test 2>&1 | tee -a work.log




7) YUM

- Yum descends philosophically from Yellowdog Linux's updater tool yup but was rebuilt to process .rpm packages.

- RPM can only look one step ahead in the dependency tree for a particular package. Yum can perform recursive dependency resolution.

- The main insight of yum was to split off the package headers, so that they could be downloaded and analysed separately, allowing dependency resolution without downloading or processing the entirety of each dependency package.

- Yum depends on RPM.
-- Yum queries the local RPM database to examine what packages are installed already. Updates can replace existing packages or require new packages to be added, so it is necessary to process and resolve lots of package metadata.
-- For any packages to be installed, Yum either downloads them via the network or accesses them locally. It then uses the RPM library to examine a transaction set of packages further in order to find out whether there are any dependency problems or conflicts before asking RPM to perform a transaction.

- Yum splits off the headers and metadata on the repository side (using
createrepo
or any of several other repo management tools). The headers themselves are sorted, XML encoded, and compressed, and are then available to be downloaded separately and quickly to the yum client where they are typically cached semi-permanently and periodically updated. All of yum's dependency resolution proceeds from analysis of these cached header files.

- A yum client can be configured to maintain local copies of a relevant subset of packages, by caching the rpm package files when they are downloaded for an install or update.



8) RPM

A computer system administrator must have some sort of mechanism for updating the packages already installed on their system(s) to the latest, patched, secure, debugged, trusted versions and for adding more packages, including ones that may not have been in the distribution they relied upon for their original base install.

RPM is a powerful Package Manager, which can be used to build, install, query, verify, update, and erase individual software packages.

An rpm package consists of basically three parts: a header, a signature, and the (generally compressed) archive itself.

The header contains a complete file list, a description of the package, a list of the features and libraries it provides, a list of tools it requires (from other packages) in order to function, what (known) other packages it conflicts with, scripts, and more.

Scripts may be specified to run after installation, before uninstallation, during verification, etc.

A basic rpm tool needs information in the header to permit a package to be installed (or uninstalled) in such a way that:
- Installing the package breaks none of the already installed packages (recursively, as they may need packages of their own to be installed).
- All the packages that the package requires for correct operation are also (or already) installed along with the selected package, recursively.
- A later version of the package does not (accidentally) replace an earlier version of the package.
Note that a similar list applies to uninstallation. For example, removing a package must not break any packages left behind.

RPM was the original tool for managing .rpm packages. The package format and the RPM package manager were designed and built at Red Hat.

RPM can only look one step ahead in the dependency tree for a particular package.

RPM depends on GPG for key operations. Importing a key into the RPM database does not seem to cause GPG to import the key into the GPG keyring database.

Packages come in two varieties: binary packages, used to encapsulate software to be installed, and source packages, containing the source code and recipes necessary to produce binary packages.

For RPM, a "conflict" can be:
- A new package wants to install a file, but a previous package has already placed a file in the desired location.
- An attempt to install an already installed package.
- An attempt to install an older package over a newer version.
- A package contains a warning from the developer that another package is incompatible.

RPM keeps track of all the files it installs in a database. Each file's database entry contains a variety of information about the file, including an MD5 checksum. During an update or install, RPM can use the MD5 checksum to determine if a particular file is going to be replaced by a file with the same name but different contents.

I have discovered from the book Maximum RPM that the rpm database can be used to check the validity of the filesystem state (or rather, the validity of the section of the filesystem state that is described by the packages in the rpm database). This can be done by using the --verify option and selecting all packages with the --all option.

- Every time a package is installed, upgraded, or erased, the changes are logged in RPM's database.
- The RPM database reflects the configuration of the system on which it resides.
- When RPM accesses the database to see how files should be manipulated during an install, upgrade, or erase, it is using the database as a mirror of the system's configuration.
- It is also possible to use the system configuration as a mirror of the RPM database.
- You can then see if the system configuration accurately reflects the contents of the RPM database.

RPM's verification process is strict. Changing configuration files or file attributes will cause these files to fail verification.

Configuration files are normally changed in order to customise the behaviour of installed software. Overwriting these files would erase existing customisations. If a new version of the package is to be installed, RPM performs various checks on the original, existing, and new configuration files. If it can't make a good choice, it will make a backup copy of the existing consideration file and then replace it with the new file.

A package will contain a declaration that a particular file is a config file.



9) RPM - FURTHER DETAILS

The --test option can be used with
rpm --install [package_file_path]
to simulate installing the package, in order to check for and report potential conflicts.

As long as the requiring and the providing packages are installed using the same invocation of RPM, the dependency checking will succeed. For example, the command
rpm -ivh *.rpm
will properly check for dependencies, even if the requiring package ends up being installed before the providing package.

I used
rpm -iv
, or rather
rpm --install --verbose
.

Final command and its output:

[root@kalkin rpms]# rpm --install gcc-4.4.7-18.el6.x86_64.rpm cloog-ppl-0.15.7-1.2.el6.x86_64.rpm cpp-4.4.7-18.el6.x86_64.rpm glibc-devel-2.12-1.209.el6.x86_64.rpm glibc-headers-2.12-1.209.el6.x86_64.rpm kernel-headers-2.6.32-696.el6.x86_64.rpm libgomp-4.4.7-18.el6.x86_64.rpm mpfr-2.4.1-6.el6.x86_64.rpm ppl-0.10.2-11.el6.x86_64.rpm --verbose

Preparing packages for installation...
ppl-0.10.2-11.el6
cloog-ppl-0.15.7-1.2.el6
mpfr-2.4.1-6.el6
cpp-4.4.7-18.el6
libgomp-4.4.7-18.el6
kernel-headers-2.6.32-696.el6
glibc-headers-2.12-1.209.el6
glibc-devel-2.12-1.209.el6
gcc-4.4.7-18.el6



The --package option is required in order to target an uninstalled package file.

Normal packages contain the compiled code and the items necessary for running it.

Development packages (with the suffix "-devel" or "-dev") usually contain all the files necessary to compile code against a given library (i.e. "develop" against it).


The "compat-" prefix in a package name indicates a focus on compatibility with code built on a previous Centos version.
Example: compat-gcc-34-3.4.6-19.el6.x86_64.rpm
RHEL6 compat-gcc-34 == gcc 3.4 for compatibility with code designed to be built under RHEL4


RPM key ring management is performed exactly like package management. Key packages can be queried and erased. For example, all currently imported public keys can be displayed by running:

# rpm -qa gpg-pubkey*


This is equivalent to running:

# rpm --query --all gpg-pubkey*



The default database location for RPM is
/var/lib/rpm
.


The header and the data archive in an RPM package appear to have separate digital signatures.

Data from a file's RPM package header may include:
- name
- epoch
- version
- release
- arch
- excludearch and exclusivearch lists
- dependency details
- package capabilities
- virtual package names
- library SONAMEs
- obsoletes
- conflict definitions
- filelists


The command
rpm --query --package [package_file_path] --dump
lists 9 properties for each file in a package:
- path = the absolute file path.
- size = the file size in bytes.
- mtime = time of last modification in seconds past the Unix zero date of 1 January 1970.
- digest = 128-bit MD5 checksum of the file's contents.
- mode = 6- or 7-digit number that describes the file's type and its permissions.
- owner = user identity that has ownership permissions for this file.
- group = group identity that has group access permissions for this file.
- isconfig = 0 or 1, indicating whether or not this file is a configuration file.
- isdoc = 0 or 1, indicating whether or not this file is a documentation file.
- rdev = 0 or [unknown], indicating whether or not this file is a device file.
- symlink = "X" or a path, indicating whether or not this file is a symbolic link to another file.

Note: [unknown] indicates that I don't currently know what a non-zero value would be or how it might be formatted.

When a package is built by RPM, if any file in the package's
%files
list is a shared library, the library's soname is automatically added to the list of capabilities the package provides. The soname is the name used to determine compatibility between different versions of a library.
- Note that this is not a filename. In fact, no aspect of RPM's dependency processing is based on filenames. Many people new to RPM often make the assumption that a failed dependency represents a missing file. This is not the case.

RPM's dependency processing is based on knowing what capabilities are provided by a package and what capabilities a package requires.


Dependency list for the gcc package:

[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --requires

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
/bin/sh
/bin/sh
/bin/sh
/sbin/install-info
/sbin/install-info
binutils >= 2.19.51.0.14-33
cloog-ppl >= 0.15
cpp = 4.4.7-18.el6
glibc-devel >= 2.2.90-12
libc.so.6()(64bit)
libc.so.6(GLIBC_2.11)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libgcc >= 4.4.7-18.el6
libgcc_s.so.1()(64bit)
libgomp = 4.4.7-18.el6
libgomp.so.1()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1



My current best explanation of the types of dependency shown in the example above:
- /bin/sh == file
- { binutils >= 2.19.51.0.14-33 } == a package, with a specified version number range.
- { cpp = 4.4.7-18.el6 } == a package, with a specified version number.
- { libc.so.6()(64bit) } == a shared library, with a specified CPU architecture type
- { libc.so.6(GLIBC_2.11)(64bit) } == a shared library, with a specified version number and a specified CPU architecture type
- { rpmlib(CompressedFileNames) <= 3.0.4-1 } == an internal RPM dependency, i.e. this package requires certain capabilities to be present in the version of RPM that processes it.
- { rtld(GNU_HASH) } is provided by glibc-2.12-1.209.el6.x86_64. I am unsure what it is, exactly.


It seems that when a executable file is compiled from source code, it includes the names of the shared libraries that it depends on.
- These names are "sonames" and presumably have this sort of format: "libc.so.6"
- The
ldd
tool can extract the names of these shared libraries.
-- This is used in the construction of the list produced by using the --requires option.

Note (from the output of the --requires option) that shared library files have versions, and that these versions can be specified in a package's requirements.

It looks as though a shared library file contains details that declare it to be a shared library file. The soname can be extracted from a shared library file.
- This is used in the construction of the list produced by using the --provides option.


rpmlib() dependencies are provided by the running RPM instance, and cannot be provided by packages.

rpmlib can change as RPM goes through version changes. It is involved in tracking backwards-incompatible changes in the way that RPM handles packages.

rpm --showrc
displays the internal dependencies.

In the rpm --showrc output, specific rpm version numbers are listed with each dependency { rpmlib(VersionedDependencies) = 3.0.3-1 }. It looks like this means something like "in this rpm installation, the dependency rpmlib(VersionedDependencies) is available, and its version is that which was first included in rpm in rpm version 3.0.3-1".
- Exception: rpmlib(PayloadIsXz) = 5.2-1, but rpm on Kalkin is version 4.8.0. In this case, 5.2-1 may be the version number of the xz tool, used for compressing packages.


{ gdb < 5.1-2 } appears in the output of
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --conflicts


The Conflicts tag is used within a package to specify which packages conflict with it. RPM will not permit conflicting packages to be installed unless overridden with the
--nodeps
option.

Any version of the package gdb that is below version 5.1-2 will conflict with the package gcc-4.4.7-18.





THOUGHTS



Tentative algorithm for using RPM to perform an offline installation of a package:
- Download package.
- Transfer package to destination computer.
- Perform a test install with RPM. This will report missing dependencies.
-- These dependencies may be:
--- package names (with optional version or version range)
--- shared libraries (with optional library version and optional cpu architecture type)
--- particular files at specified locations.
--- rpmlib capabilities (with version) that indicate that this package requires a specific version or version range of rpm
--- something like rtld(GNU_HASH) (provided by glibc).
- Look up each dependency in a package database that provides search capability. Make a list of the packages that provide these dependencies.
- Repeat this process for all these new packages.
- When no new dependencies are reported missing, construct and run a single command that will tell RPM to install all these packages.


Example of downloading a package: Browse to
mirror.centos.org/centos/6/os/x86_64/Packages
and download gcc-4.4.7-18.el6.x86_64.rpm by clicking its name, which is a link.

Example of a test install command:

rpm --install rpms/gcc-4.4.7-18.el6.x86_64.rpm --test


Example package database:
pkgs.org

Note: The package database must be constructed by examining the --provides output for each package (which describes the dependencies/capabilities that the package provides), then making an entry that links the name of each capability back to the name of the package, thus allowing a search for the capability to return the package.
- This would not be necessary if the --requires output for each package included the name of the package that provides a dependency/capability, not just the name of the dependency/capability itself.

Example of an install command:

rpm --install gcc-4.4.7-18.el6.x86_64.rpm cloog-ppl-0.15.7-1.2.el6.x86_64.rpm cpp-4.4.7-18.el6.x86_64.rpm glibc-devel-2.12-1.209.el6.x86_64.rpm glibc-headers-2.12-1.209.el6.x86_64.rpm kernel-headers-2.6.32-696.el6.x86_64.rpm libgomp-4.4.7-18.el6.x86_64.rpm mpfr-2.4.1-6.el6.x86_64.rpm ppl-0.10.2-11.el6.x86_64.rpm --verbose



An excerpt from the Discoveries section:

For RPM, a "conflict" can be:
- A new package wants to install a file, but a previous package has already placed a file in the desired location.
- An attempt to install an already installed package.
- An attempt to install an older package over a newer version.
- A package contains a warning from the developer that another package is incompatible with it.


Other types of conflicts:
- A script on the computer system may call out to the OS to run a command and rely on its particular behaviour. Removing or upgrading the package that supplies this command may break the script.
- A compiled program on the computer system may dynamically link to the shared libraries provided by particular packages. Removing or upgrading the packages that supply these shared libraries may break the program.


An excerpt from the Discoveries section:

Using the RPM database as a mirror of the system state, or vice versa:
- Every time a package is installed, upgraded, or erased, the changes are logged in RPM's database.
- The RPM database reflects the configuration of the system on which it resides.
- When RPM accesses the database to see how files should be manipulated during an install, upgrade, or erase, it is using the database as a mirror of the system's configuration.
- It is also possible to use the system configuration as a mirror of the RPM database.
- You can then see if the system configuration accurately reflects the contents of the RPM database.


I think these observations apply to any situation where:
- a system exists
- an attempt is made to track its state using an information system

Examples: Inventory management, bookkeeping.



Excerpt from:
webhome.phy.duke.edu/~rgb/General/yum_HOWTO/yum_HOWTO/yum_HOWTO-1.html
Author: Robert G. Brown

A moment or two of meditation upon dependency resolution should suffice to convince one that Great Evil is possible in a large rpm repository. You have hundreds, perhaps thousands of rpm packages. Some are commercial, some are from some major distribution(s), others are local homebrew. What if, in all of these packages built at different times and by different people, you ever find that there exist rpm's such that (e.g.) rpm A requires rpm B, which conflicts with rpm C (already installed)? What if rpm A requires rpm B (revision 1.1.1) but rpm B (revision 1.2.1) is already installed and is required in that revision by rpm C (also already installed)? What if you install an application from source that replaces critical dependencies for installed packages that may not be compatible? What if you install a commercial package that requires an obsolete library to function?



Thoughts:
- Many software items will eventually need a way to store their settings. The simplest method of storing settings is a text file in a particular format i.e. a configuration file. A new version of a software item may have different default settings or use a new format for its configuration file(s).
- Package managers need to handle the changing state and format of the config file(s) of each software item.
- Package managers have to handle the different versions and config files of software items that are targeted at different CPU architectures.
- Harder problem: A package manager that handles new formats for its packages, public keys, and digital signatures.
- Even harder problem: A package manager that handles the changing code, state, and config file format of its own self.
- A package manager is a formalised method of moving software items onto a computer system. Software items are big heaps of state. Software items are prone to try to interfere with one another's state.
- A software item's state can be thought of as its territory within the environment of the computer system's filesystem. RPM is a manager that tries to stop software items from seizing each other's territory.
- A package is a large patch on the state of a computer system.
-- For this patching to work consistently, a section of the computer system should be designated as the territory of the package manager. In the case of RPM, this would appear to be the entire
/usr
directory. The user should not interfere with this territory, and should only make changes to it by issuing commands to the package manager. Exception: user edits to config files.




What is a software item?

There is no real fundamental difference between code and data. There are only zeros and ones, stored in various locations on a computer system.

A computer system is configured to read a specific series of zeros and ones from a specific location when it is powered on. So one location on the computer contains the boot-up procedure (code), while another could contain a text file (data), but they both contain the same type of item, i.e. a series of zeros and ones.

I'm going to define "software item" as "a series of zeros and ones". This can be a piece of code, a compiled program, a text file, or any other type of item that might exist on a computer system.

The smallest software item is a single bit, of value 0 or 1. In practice, a computer system usually uses a larger minimum unit e.g. an octet (8 bits), so the smallest software item is then a series of 8 bits, each of value 0 or 1. An octet is commonly known as a byte.

Here's an example of creating a software item of the smallest size:

echo -n "a" > item.txt


The character "a", in ASCII, is a single byte: 01100001

Note: A computer system will wrap the data "a" with more information that indicates that the item is a file.

In the example above, I have actually installed a software item. I have installed a single file named "item.txt", containing the data "a", into the current directory. A "package" containing data and instructions for performing this installation might be, roughly, "place a file object containing the data 01100001 into the current directory".

A package manager, such as RPM, performs many operations of various types, but they are all reducible to adding/checking/replacing/deleting various series of zeros and ones, until the computer system has been changed from its original state into the desired state.

This is similar to the idea of CRUD in web application development, although in that case the focus is usually on controlling the state of a database, rather than a filesystem.
CRUD == Create/Retrieve/Update/Delete

Note: A file system can be considered to be a type of database.

This is also similar to the idea of a patch in code development, where the focus is on managing the contents (i.e. the state) of a set of files. A package is a large patch on the state of a computer system.

There is no theoretical barrier to manually performing an offline installation of an rpm package. I could read the package data and the RPM application code (both displayed on another computer), manually type the package data into the second offline computer, and perform exactly the same operations that RPM would (writing code to do so if necessary). It would simply take a very long time. Also, if I made any mistakes, searching for them would be like working in Borges' Library.

A filesystem contains various types of item, with defined properties. Examples: File, directory, device file. The filesystem operations of a package manager are necessarily limited to adding/checking/replacing/deleting these items and their properties. A package manager may also maintain a separate database of these items, so as to record additional properties for them. Example: rpm packages may declare some of their files to be "config files". An RPM client records this information in its database, so that later it can remember that these files are config files, and apply special rules when they are involved in an operation.

So far, I have seen that an rpm package can specify these file properties:
- path = the absolute file path.
- size = the file size in bytes.
- mtime = time of last modification in seconds past the Unix zero date of 1 January 1970.
- digest = 128-bit MD5 checksum of the file's contents.
- mode = 6- or 7-digit number that describes the file's type and its permissions.
- owner = user identity that has ownership permissions for this file.
- group = group identity that has group access permissions for this file.
- isconfig = 0 or 1, indicating whether or not this file is a configuration file.
- isdoc = 0 or 1, indicating whether or not this file is a documentation file.
- rdev = 0 or [unknown], indicating whether or not this file is a device file.
- symlink = "X" or a path, indicating whether or not this file is a symbolic link to another file.

Note: [unknown] indicates that I don't currently know what a non-zero value would be or how it might be formatted.

Additionally, if RPM installs a shared library file, it will run
ldconfig
to make the new shared library accessible. I think this means that an adjustment is made to a filesystem property of the shared library file. Something similar may be done to executable files.

Conclusion: In theory, a "software item" can be defined as "a series of zeros and ones". In practice, a "software item" that can be installed on a filesystem is perhaps more accurately defined as "a series of zeros and ones, of a specified filesystem object type, with a collection of specified filesystem properties, optionally with scripts that may adjust additional filesystem properties after installation, and optionally with extra properties defined by a package management system that are stored in a database administered by the package manager application".






Thoughts:
- Dependencies should ideally include the package name. The package name should be always the index for looking up any of its items/properties.
- Currently, in order to find a package that contains a particular dependency, it is necessary to collect all packages (or at least as many as possible), examine them to see which capabilities/dependencies they provide, compile a list of the results, and search this list for the dependency. pkgs.org does this (or something very similar).
-- Note: Sometimes the package name can be guessed from the dependency name, but not always.

Examples:
- rtld(GNU_HASH) is provided by glibc-2.12-1.209.el6.x86_64.
In the requirements list, it could perhaps be named
glibc-2.12-1.209.el6.x86_64[rtld(GNU_HASH)].
- libc.so.6()(64bit) is provided by glibc-2.12-1.209.el6.x86_64.
In the requirements list, it could perhaps be named
glibc-2.12-1.209.el6.x86_64[libc.so.6()(64bit)].
- libgomp.so.1()(64bit) is provided by libgomp-4.4.7-18.el6.x86_64.
In the requirements list, it could perhaps be named
libgomp-4.4.7-18.el6.x86_64[libgomp.so.1()(64bit)].



Thoughts:
- Scenario: rpm C is already installed. You wish to install rpm A. rpm A requires rpm B, which conflicts with rpm C.
- rpms conflict when they want the same filesystem territory.
- This scenario may occur when the writer of rpm A does not have rpm C installed. On the writer's computer system, the conflict does not exist.
- Possible solution: rpm A could be built with static linking, in which case rpm B would be included within the resulting binary.
- Question: If distributing rpm A as source code rather than as a compiled binary, could it be compiled on the destination computer system, using static linking?
-- If rpm C is already installed, then rpm B can not be installed. rpm B would however be necessary for compilation on the destination computer system. A different base directory would have to be created and treated as root. Then rpm B could be compiled and installed at this temporary root directory, and used for compiling a static version of rpm A. Static compilation of rpm A would mean that the resulting binary could still be run even after the temporary root directory has been deleted (along with the installation of rpm B that it contained).
--- I'm fairly sure that the approach that I describe in the preceding paragraph was used in the recipe I followed when I compiled bitcoind (trb 0.5.4) on Debian 7.11.
--- From some reading, it appears that
buildroot
is the tool used to create a temporary root directory, below which packages can be installed. It will appear to be the root directory of a normal Linux filesystem, which is what the packages expect to see.



In a package management system, conflicts between packages are inevitable unless all writers always work with the entire set of packages installed on every development machine.

If running a package management system on a computer system:
- Need an interface for viewing conflicts between packages.
- Need a process for resolving, avoiding, or living with package conflicts.
- Perhaps it should be possible to never delete old packages, in case this breaks scripts, dynamically linked compiled programs, or compilation processes for statically linked compiled programs.
-- This would mean that a script that used perl 4 could coexist with another that used perl 5.
-- Scripts should not call out to "python" or "perl" but instead should specify a version in each call e.g. "python[2.7.13]".
--- This could perhaps be set in a single location in the script, and then all calls to "python" elsewhere in the script would resolve to "python[2.7.13]".
- Could perhaps have a script/program registry for keeping track of which dependencies each script/program relied on, so that you could remove an old package, but know beforehand which things might break.












PROJECT LOG



I need a compiler, which will allow me to compile source code into machine code, which can then be run on Kalkin. Much of current software is written in C, including various items that I wish to install on Kalkin, so this compiler should be able to compile C. I would also like to be able to compile some C++ items, so I'll look for a compiler that can handle C++ as well, if it doesn't add too much complexity to this project.

I don't want to use a package manager, connect to the internet, install the dependency tree that is currently available, and try to work out afterwards what was installed. I want to install the necessary items in the right order and preserve them as assets attached to this article.


Definition of "compile" from:
techterms.com/definition/compile
Author: Per Christensson
Updated: December 2, 2008

When programmers create software programs, they first write the program in source code, which is written in a specific programming language, such as C or Java. These source code files are saved in a text-based, human-readable format, which can be opened and edited by programmers. However, the source code cannot be run directly by the computer. In order for the code to be recognized by the computer's CPU, it must be converted from source code (a high-level language) into machine code (a low-level language). This process is referred to as "compiling" the code.

Most software development programs include a compiler, which translates source code files into machine code or object code. Since this code can be executed directly by the computer's processor, the resulting application is often referred to as an executable file. Windows executable files have a .EXE file extension, while Mac OS X programs have an .APP extension, which is often hidden.



The compiler program will have to already be compiled machine code itself in order for me to be able to run it.

Also, the compilation of this program will need to have been targeted at the particular CPU architecture of Kalkin's CPU.

In Kalkin's specs, I can see that its CPU is:
- Processor (CPU): Intel Xeon E3-1230 Quad Core 3.20GHz - 8MB Smart Cache - 3.60GHz Turbo Boost

While making a Centos 6.9 bootable USB memory stick, I found out that this CPU's architecture is x86_64.


gcc is one of the most common compiler programs. gcc stands for GNU Compiler Collection.



Google "gcc".

Excerpt from:
gcc.gnu.org
Last modified 2018-01-30.

GCC, the GNU Compiler Collection

The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Ada, and Go, as well as libraries for these languages (libstdc++,...). GCC was originally written as the compiler for the GNU operating system.




Browse to a previous article:
Listing available tools on Centos 6.9 Minimal
Download available_tools_on_centos_69_minimal.txt.


"Aineko" is the name of my current main work computer (a Macbook in clamshell mode with an external monitor attached).

aineko:Downloads stjohnpiano$ grep gcc available_tools_on_centos_69_minimal.txt



Move over to Kalkin:

[root@kalkin ~]# gcc --version
-bash: gcc: command not found



gcc is apparently not available by default.


Excerpt from:
stackoverflow.com/questions/9644321/install-gcc-c-on-centos-without-yum

Q:

Can I install gcc++ on CentOS 6.x without `yum install gcc-c++ ....' ?

Is there any .tar or .rpm package available for download?

asked Mar 10 '12 at 6:02
user113454


A:

Yum will install rpm from it's repository.

So I don't understand why you want to avoid yum, it will solve dependencies and install them as well.

However, here is official RPM repository mirror (one of many): http://centos.arminco.com/5/os/i386/CentOS/

Here is list of all mirrors : http://www.centos.org/modules/tinycontent/index.php?id=30

You will need at least 3 RPMs:

- gcc-4.4.6-3.el6.i686.rpm
- gcc-c++-4.4.6-3.el6.i686.rpm
- libgcc-4.4.6-3.el6.i686.rpm

For compilation of C/C++ you will also need libstdc++, glibc, etc

When you run

yum install gcc


Everything is done

As you did not specified architecture I assume i386, but URL is very similar for x86_64:

http://centos.arminco.com/6/os/x86_64/Packages/

edited Jan 27 '17 at 7:05
answered Mar 10 '12 at 6:38
rkosegi



Key section: "You will need at least 3 RPMs:
- gcc-4.4.6-3.el6.i686.rpm
- gcc-c++-4.4.6-3.el6.i686.rpm
- libgcc-4.4.6-3.el6.i686.rpm
For compilation of C/C++ you will also need libstdc++, glibc, etc"


Browsing to
centos.arminco.com/5/os/i386/CentOS
produces a search results page from my ISP (the specified page cannot be found).

Browsing to
www.centos.org/modules/tinycontent/index.php?id=30
leads to the main page on
wiki.centos.org

Browsing to
centos.arminco.com/6/os/x86_64/Packages
produces a search results page from my ISP (the specified page cannot be found).





Excerpts from:
gcc.gnu.org/wiki/InstallingGCC


Installing GCC

This page is intended to offer guidance to avoid some common problems when installing GCC, the official installation docs are in the Installing GCC [ http://gcc.gnu.org/install/index.html ] section of the main GCC documentation. N.B. those installation docs refer to the development trunk, the installation instructions for released versions are included in the release sources.

For most people the easiest way to install GCC is to install a package made for your operating system. The GCC project does not provide pre-built binaries of GCC, only source code, but all GNU/Linux distributions include packages for GCC.

[...]

If you cannot find suitable binaries for your system, or you need a newer version than is available, you will need to build GCC from source in order to install it.

[...]


Building GCC

Many people rush into trying to build GCC without reading the installation docs [ http://gcc.gnu.org/install/index.html ] properly and make one or more of these common mistakes:

- do not run ./configure from within the source directory, this is not supported. You need to run configure from outside the source directory, in a separate directory created for the build (this is a FAQ [ http://gcc.gnu.org/wiki/FAQ#configure ])

- if GCC links dynamically to the GMP, MPFR or MPC support libraries then the relevant shared libraries must be in the dynamic linker's path, both when building gcc and when using the installed compiler (this is also a FAQ [ http://gcc.gnu.org/wiki/FAQ#configure_suffix ])


Support libraries

See Installing GCC: Prequisites [ http://gcc.gnu.org/install/prerequisites.html ] for the software required to build GCC. If you do not have the GMP, MPFR and MPC support libraries already installed as part of your operating system then there are two simple ways to proceed, and one difficult, error-prone way. For some reason most people choose the difficult way. The easy ways are:

- If it provides sufficiently recent versions, use your OS package management system to install the support libraries in standard system locations. For Debian-based systems, including Ubuntu, you should install the packages
libgmp-dev
,
libmpfr-dev
and
libmpc-dev
. For RPM-based systems, including Fedora and SUSE, you should install
gmp-devel
,
mpfr-devel
and
libmpc-devel
(or
mpc-devel
on SUSE) packages. The packages will install the libraries and headers in standard system directories so they can be found automatically when building GCC.

- Alternatively, after extracting the GCC source archive, simply run the
./contrib/download_prerequisites
script in the GCC source directory. That will download the support libraries and create symlinks, causing them to be built automatically as part of the GCC build process. Set
GRAPHITE_LOOP_OPT=no
in the script if you want to build GCC without ISL, which is only needed for the optional Graphite loop optimizations.

- The difficult way, which is not recommended, is to download the sources for GMP, MPFR and MPC, then configure and install each of them in non-standard locations, then configure GCC with
--with-gmp=/some/silly/path/gmp --with-mpfr=/some/silly/path/mpfr --with-mpc=/some/silly/path/mpc
, then be forced to set
LD_LIBRARY_PATH=/some/silly/path/gmp:/some/silly/path/mpfr:/some/silly/path/mpc/lib
in your environment forever. This is silly and causes major problems for anyone who doesn't understand how dynamic linkers find libraries at runtime. Do not do this. If building GCC fails when using any of the
--with-gmp
or
--with-mpfr
or
--with-mpc
options then you probably shouldn't be using them.



From this, I see that GCC requires these support libraries:
- GMP
- MPFR
- MPC

On RPM-based systems (e.g. Centos), these are called:
- gmp-devel
- mpfr-devel
- libmpc-devel (or mpc-devel)

I also see that the package manager will be able to figure out where to install these libraries:
"The packages will install the libraries and headers in standard system directories so they can be found automatically when building GCC."
and that it is possible to install them in custom locations:
"set
LD_LIBRARY_PATH=/some/silly/path/gmp:/some/silly/path/mpfr:/some/silly/path/mpc/lib
in your environment"

In e.g. "gmp-devel", "devel" probably stands for "developer version". The developer version of the library may only be necessary for attempting to build GCC from source. In order to install and run a compiled binary of GCC, I may need to install a standard support version of the GMP library instead.



What are these libraries for?


Google "gmp library".


Excerpt from:
gmplib.org

GMP is a free library for arbitrary precision arithmetic, operating on signed integers, rational numbers, and floating-point numbers. There is no practical limit to the precision except the ones implied by the available memory in the machine GMP runs on. GMP has a rich set of functions, and the functions have a regular interface.

The main target applications for GMP are cryptography applications and research, Internet security applications, algebra systems, computational algebra research, etc.

GMP is carefully designed to be as fast as possible, both for small operands and for huge operands. The speed is achieved by using fullwords as the basic arithmetic type, by using fast algorithms, with highly optimised assembly code for the most common inner loops for a lot of CPUs, and by a general emphasis on speed.

The first GMP release was made in 1991.



Google "MPFR library".


Excerpts from:
www.mpfr.org

The MPFR library is a C library for multiple-precision floating-point computations with correct rounding.

[...]

MPFR is based on the GMP multiple-precision library.

The main goal of MPFR is to provide a library for multiple-precision floating-point computation which is both efficient and has a well-defined semantics. It copies the good ideas from the ANSI/IEEE-754 standard for double-precision floating-point arithmetic (53-bit significand).



Excerpt from:
www.mpfr.org/faq.html

1. What are the differences between MPF from GMP and MPFR?

The main differences are:
- The precision of a MPFR variable is the exact number of bits used for its mantissa, whereas in MPF, the precision requested by the user is a minimum value (MPF generally uses a higher precision). With the additional difference below, this implies that the MPFR results do not depend on the number of bits (16, 32, 64 or more) of the underlying architecture.
- As a consequence, MPFR uses a base-2 exponent, whereas in MPF, this is a base-2^32 or base-2^64 exponent, depending on the limb size. For this reason (and other internal ones), the maximum exponent range in MPFR is different (and smaller, if the exponent is represented by the same type as in MPF).
- MPFR provides an additional rounding mode argument to its functions; furthermore, it is guaranteed that the result of any operation is the nearest possible floating-point value from the exact result (considering the input variables as exact values), taking into account the precision of the destination variable and the rounding mode. MPFR also says whether the rounded result is above or below the exact result.
- MPFR supports much more functions (in particular transcendental functions such as exponentials, logarithms, trigonometric functions and so on) and special values: signed zeros, infinities, not-a-number (NaN).



Evidently GMP includes a function or object called MPF ("multiple-precision floating-point").

Key section: "the MPFR results do not depend on the number of bits (16, 32, 64 or more) of the underlying architecture."
Presumably this was a problem encountered when using GMP's MPF.



Google "MPC library".

Excerpt from:
www.multiprecision.org/mpc
Last changed on 2018-01-12 by Andreas Enge

GNU MPC is a C library for the arithmetic of complex numbers with arbitrarily high precision and correct rounding of the result. It extends the principles of the IEEE-754 standard for fixed precision real floating point numbers to complex numbers, providing well-defined semantics for every operation. At the same time, speed of operation at high precision is a major design goal.

The library is built upon and follows the same principles as GNU MPFR. It is written by Andreas Enge, Mickaël Gastineau, Philippe Théveny and Paul Zimmermann.



Interesting. I wonder why GCC compilation requires complex numbers.



Well, I'm going to need these three libraries installed in the right locations on Kalkin, so that GCC can find and use them when it's compiling something. Again, because I don't have a compiler, I will need previously compiled binaries of these libraries, targeted at Kalkin's CPU architecture.


Let's see whether packages exist that contain previously compiled binaries of GCC and the GMP, MPFR, and MPC libraries. From an earlier excerpt, I see that I will probably also need:
- gcc-c++
- libgcc
- libstdc++
- glibc


Google "centos packages".

Second result:
mirror.centos.org/centos/6/os/x86_64/Packages

Note that I'm looking for Centos 6 and x86_64 architecture. The URL matches these characteristics.

Excerpts:

compat-gcc-34-3.4.6-19.el6.x86_64.rpm
compat-gcc-34-c++-3.4.6-19.el6.x86_64.rpm
compat-gcc-34-g77-3.4.6-19.el6.x86_64.rpm
compat-glibc-2.5-46.2.x86_64.rpm
compat-glibc-headers-2.5-46.2.x86_64.rpm

[...]

compat-libstdc++-33-3.2.3-69.el6.i686.rpm
compat-libstdc++-33-3.2.3-69.el6.x86_64.rpm
compat-libstdc++-296-2.96-144.el6.i686.rpm

[...]

gcc-4.4.7-18.el6.x86_64.rpm
gcc-c++-4.4.7-18.el6.x86_64.rpm
gcc-gfortran-4.4.7-18.el6.x86_64.rpm
gcc-gnat-4.4.7-18.el6.x86_64.rpm
gcc-java-4.4.7-18.el6.x86_64.rpm
gcc-objc++-4.4.7-18.el6.x86_64.rpm
gcc-objc-4.4.7-18.el6.x86_64.rpm

[...]

glibc-2.12-1.209.el6.i686.rpm
glibc-2.12-1.209.el6.x86_64.rpm
glibc-common-2.12-1.209.el6.x86_64.rpm
glibc-devel-2.12-1.209.el6.i686.rpm
glibc-devel-2.12-1.209.el6.x86_64.rpm
glibc-headers-2.12-1.209.el6.x86_64.rpm
glibc-static-2.12-1.209.el6.i686.rpm
glibc-static-2.12-1.209.el6.x86_64.rpm
glibc-utils-2.12-1.209.el6.x86_64.rpm

[...]

gmp-4.3.1-12.el6.i686.rpm
gmp-4.3.1-12.el6.x86_64.rpm
gmp-devel-4.3.1-12.el6.i686.rpm
gmp-devel-4.3.1-12.el6.x86_64.rpm
gmp-static-4.3.1-12.el6.x86_64.rpm

[...]

libgcc-4.4.7-18.el6.i686.rpm
libgcc-4.4.7-18.el6.x86_64.rpm

[...]

libmpcdec-1.2.6-6.1.el6.i686.rpm
libmpcdec-1.2.6-6.1.el6.x86_64.rpm
libmpcdec-devel-1.2.6-6.1.el6.i686.rpm
libmpcdec-devel-1.2.6-6.1.el6.x86_64.rpm

[...]

libstdc++-4.4.7-18.el6.i686.rpm
libstdc++-4.4.7-18.el6.x86_64.rpm
libstdc++-devel-4.4.7-18.el6.i686.rpm
libstdc++-devel-4.4.7-18.el6.x86_64.rpm
libstdc++-docs-4.4.7-18.el6.x86_64.rpm

[...]

mpfr-2.4.1-6.el6.i686.rpm
mpfr-2.4.1-6.el6.x86_64.rpm
mpfr-devel-2.4.1-6.el6.i686.rpm
mpfr-devel-2.4.1-6.el6.x86_64.rpm



I see gmp-devel and mpfr-devel, but not libmpc-devel / mpc-devel.
Perhaps libmpcdec-devel is the same item as libmpc-devel?


Google "libmpcdec".

Excerpt from:
rpmfind.net/linux/RPM/centos/6.9/x86_64/Packages/libmpcdec-1.2.6-6.1.el6.x86_64.html

Name: libmpcdec
Summary: Musepack audio decoding library

Musepack is an audio compression format [...] based on the MPEG-1 Layer-2 / MP2 algorithms.



Hm. Not the same.


Google "centos libmpc".

Third result:
centos.pkgs.org/6/epel-x86_64/libmpc-devel-0.8-3.el6.x86_64.rpm.html

CentOS 6: EPEL x86_64

libmpc-devel-0.8-3.el6.x86_64.rpm

Description:
libmpc-devel - Header and shared development libraries for MPC

Distribution: CentOS 6
Repository: EPEL x86_64
Package name: libmpc-devel
Package version: 0.8
Package release: 3.el6
Package architecture: x86_64
Package type: rpm
Installed size: 26.35 KB
Download size: 21.09 KB
Official Mirror: dl.fedoraproject.org

Header files and shared object symlinks for MPC is a C library.

[...]

Download:
Binary package: libmpc-devel-0.8-3.el6.x86_64.rpm
Source package: libmpc-0.8-3.el6.src.rpm

[...]

Files:
/usr/include/mpc.h
/usr/lib64/libmpc.so
/usr/share/info/mpc.info.gz



Ok, I have a source for libmpc. Note that it's for Centos 6.

I note that the centos.pkgs.org page for libmpc includes an option to download the source code and a list of the files that will be installed.

Look up:
- el6
- i686
- EPEL


Excerpts from:
unix.stackexchange.com/questions/177933/what-does-el5-and-el6-means-in-term-of-packages

Q:

What does EL5 and EL6 means in term of packages?

[...]

edited Oct 31 '15 at 23:30
Jeff Schaller

asked Jan 7 '15 at 13:08
JorgeeFG


A:

EL5 stands for Enterprise Linux 5 (Red Hat Enterprise Linux version or CentOS version) and EL6 accordingly for Enterprise Linux 6.

[...]

edited Nov 1 '15 at 0:09
Jeff Schaller

answered Jan 7 '15 at 13:45
ddeimeke



el6 = Enterprise Linux 6.


Excerpts from:
www.redhat.com/archives/rhl-list/2006-October/msg03684.html
Author: Mike A. Harris
Subject: Re: Differences betweem x86_64 and i686
Date: Sun, 29 Oct 2006


i686 code is intended to be executed on processors which are compatible with the 32 bit Intel x86 platform, which includes all Intel 32bit x86 processors up to and including the Pentium 4, etc. as well as processors from AMD and other vendors which make compatible 32bit chips.

x86_64 code is intended to be executed on processors which are compatible with the AMD64 64bit platform, including the AMD Athlon 64, AMD Opteron and related AMD chip families, and the Intel EM64T based processors.

These 64bit processors are fully backward compatible with their 32bit predecessors. So if you have a 64bit AMD Athlon 64 or Intel EM64T processor, it is up to you whether to install the 64bit x86_64 OS or the 32bit i386/i686 OS.

[...]

If you have a 32bit-only AMD or Intel CPU, then you have no choice but to install the i386 distribution. If you have a 64bit AMD or Intel EM64T CPU, then you can install either the 64bit x86_64 OS, or the 32bit i386 OS.

[...]

Another thing worth mentioning is that the 64bit x86_64 distribution does come with runtime compatibility for 32bit x86 applications [...] Many if not most 32bit apps should work under the 64bit OS properly so long as the compatible 32bit packages are installed. If you do this however, keep in mind that things like 32bit plugins for a particular application will not necessarily work with a 64bit application, so if there is an app you want to use which has 3rd party plugins which are not available as 64bit plugins, you'll either have to use the 32bit app, or not use the plugin.



Key section: "i686 code is intended to be executed on processors which are compatible with the 32 bit Intel x86 platform".

So i686 is 32-bit code and requires a 32-bit processor. My processor architecture is 64-bit, so i686 is not relevant to my goal.



Excerpt from:
fedoraproject.org/wiki/EPEL

Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL).



EPEL = Extra Packages for Enterprise Linux


I'm mildly surprised that one of GCC's dependencies (libmpc) does not appear within the list of available packages at mirror.centos.org, and is instead only available from another organisation.






Let's do some research on the various packages that I haven't looked at yet.


Excerpt from:
access.redhat.com/solutions/19458

Compatibility packages are available to provide build compatibility with code designed to be built under earlier releases:

RHEL7:
compat-gcc-44 (gcc 4.4.7 for compatibility with code designed to be built under RHEL6)

RHEL6:
compat-gcc-34 (gcc 3.4 for compatibility with code designed to be built under RHEL4)



RHEL = Red Hat Enterprise Linux.

So "compat-" prefix in a package name indicates a focus on compatibility with code built on a previous Centos version.

Compability won't be relevant for this project.



Google "glibc".

Excerpt from:
www.gnu.org/software/libc

What is glibc?

The GNU C Library project provides the core libraries for the GNU system and GNU/Linux systems, as well as many other systems that use Linux as the kernel. These libraries provide critical APIs including ISO C11, POSIX.1-2008, BSD, OS-specific APIs and more. These APIs include such foundational facilities as
open
,
read
,
write
,
malloc
,
printf
,
getaddrinfo
,
dlopen
,
pthread_create
,
crypt
,
login
,
exit
and more.

The GNU C Library is designed to be a backwards compatible, portable, and high performance ISO C library. It aims to follow all relevant standards including ISO C11, POSIX.1-2008, and IEEE 754-2008.

The project was started circa 1988 and is almost 30 years old.



API = Application Programming Interface.




Google "libstdc++".

Excerpt from:
gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.what

1.1. What is libstdc++?

The GNU Standard C++ Library v3 is an ongoing project to implement the ISO 14882 C++ Standard Library as described in clauses 20 through 33 and annex D (prior to the 2017 standard the library clauses started with 17).



I think libstdc++ fulfills the same role for C++ that glibc does for C.



Google "gcc-c++".

Excerpt from:
rpmfind.net/linux/rpm2html/search.php?query=gcc-c%2B%2B

RPM resource gcc-c++

This package adds C++ support to the GNU C compiler. It includes support for most of the current C++ specification, including templates and exception handling. It does include the static standard C++ library and C++ header files; the library for dynamically linking programs is available separately.





Google "libgcc".

Excerpt from:
gcc.gnu.org/onlinedocs/gccint/Libgcc.html


The GCC low-level runtime library

GCC provides a low-level runtime library, libgcc.a or libgcc_s.so.1 on some platforms. GCC generates calls to routines in this library automatically, whenever it needs to perform some operation that is too complicated to emit inline code for.

Most of the routines in libgcc handle arithmetic operations that the target processor cannot perform directly. This includes integer multiply and divide on some machines, and all floating-point and fixed-point operations on other machines. libgcc also includes routines for exception handling, and a handful of miscellaneous operations.

Some of these routines can be defined in mostly machine-independent C. Others must be hand-written in assembly language for each processor that needs them.






Hm. Let's think about how to perform the installation.



Google "centos install gcc without network".

Excerpt from:
unix.stackexchange.com/questions/89305/how-to-install-gcc-without-internet-connection

Q: How to install [ gcc ] without internet connection?

[...]

edited Sep 3 '13 at 20:15
asked Sep 3 '13 at 19:55
User3432423423


A:

You can use
yum
to do the installation too.

$ yum --nogpgcheck localinstall *.rpm


Yum will then make sure that the dependencies are all set before attempting to install. It will even look into the proposed .rpm files you're attempting to install to make sure that their dependencies are satisfied.

In general it's usually a bad idea to attempt to install multiple .rpm files using single
rpm -ivh ...
. Better to include them all on one command line so that
rpm
can check the dependencies across the entire set of .rpms too.

answered Sep 3 '13 at 20:10
slm




Hm. I didn't know that yum could be used to install .rpm packages directly from a directory. Hopefully, if dependencies are missing, it will report which ones it can't find.

The use of the flag
--nogpgcheck
indicates that yum normally uses gpg to check a package during installation.


What is yum, exactly? I've used it, and I know it's a package manager tool, but I don't know its history or design parameters.


Excerpt from:
access.redhat.com/solutions/9934

What is yum?

yum
is the primary tool for getting, installing, deleting, querying, and managing Red Hat Enterprise Linux RPM software packages from official Red Hat software repositories, as well as other third-party repositories.
yum
is used in Red Hat Enterprise Linux versions 5 and later. Versions of Red Hat Enterprise Linux 4 and earlier used up2date.



Excerpt from:
wiki.centos.org/PackageManagement/Yum

Yellow dog Updater, Modified (Yum) is the default package manager used in CentOS ( all versions ). It is used to install and update packages from CentOS (and 3rd party) Repositories [ http://wiki.centos.org/Repositories ].



Excerpt from:
wiki.centos.org/Repositories

There are several repositories provided by CentOS and other 3rd party developers that offer software packages that are not included in the default base and updates repositories. While no list can be 100% complete, as anyone may announce an archive, it represents some major efforts and provides a summary of what each repository offers. These repositories have varying levels of stability, support and cooperation within the CentOS community.



Excerpts from:
access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/ch-yum

CHAPTER 8. YUM

Yum is the Red Hat package manager that is able to query for information about available packages, fetch packages from repositories, install and uninstall them, and update an entire system to the latest available version. Yum performs automatic dependency resolution on packages you are updating, installing, or removing, and thus is able to automatically determine, fetch, and install all available dependent packages.

Yum can be configured with new, additional repositories, or package sources, and also provides many plug-ins which enhance and extend its capabilities. Yum is able to perform many of the same tasks that RPM can; additionally, many of the command-line options are similar. Yum enables easy and simple package management on a single machine or on groups of them.

[...]

Yum provides secure package management by enabling GPG (Gnu Privacy Guard; also known as GnuPG) signature verification on GPG-signed packages to be turned on for all package repositories (i.e. package sources), or for individual repositories. When signature verification is enabled, Yum will refuse to install any packages not GPG-signed with the correct key for that repository. This means that you can trust that the RPM packages you download and install on your system are from a trusted source, such as Red Hat, and were not modified during transfer. See Section 8.4, "Configuring Yum and Yum Repositories" [ http://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-Configuring_Yum_and_Yum_Repositories ] for details on enabling signature-checking with Yum, or Section B.3, "Checking a Package's Signature" [ http://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s1-check-rpm-sig ] for information on working with and verifying GPG-signed RPM packages in general.



I'm interested to see that yum can be configured to use GPG signature verification for packages. Future question: How to tell yum which GPG key corresponds to which repository?


What is RPM?


Google "rpm package management".


Excerpt from:
access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/ch-rpm

CHAPTER 12. PACKAGE MANAGEMENT WITH RPM

The RPM Package Manager (RPM) is an open packaging system, which runs on Red Hat Enterprise Linux as well as other Linux and UNIX systems. Red Hat, Inc. encourages other vendors to use RPM for their own products. RPM is distributed under the terms of the GPL.

The utility works only with packages built for processing by the
rpm
package. For the end user, RPM makes system updates easy. Installing, uninstalling, and upgrading RPM packages can be accomplished with short commands. RPM maintains a database of installed packages and their files, so you can invoke powerful queries and verifications on your system.



GPL = GNU General Public License

GNU is a recursive acronym for "GNU's Not Unix!".



Excerpts from:
webhome.phy.duke.edu/~rgb/General/yum_HOWTO/yum_HOWTO/yum_HOWTO-1.html
Author: Robert G. Brown

Yum is a tool for automating package maintenance for a network of workstations running any operating system that use the Red Hat Package Management (RPM) system for distributing packaged tools and applications. It is derived from yup, an automated package updater originally developed for Yellowdog Linux, hence its name: yum is "Yellowdog Updater, Modified".

Yup was originally written and maintained by Dan Burcaw, Bryan Stillwell, Stephen Edie, and Troy Bengegerdes of Yellowdog Linux (an RPM-based Linux distribution that runs on Apple Macintoshes of various generation). Yum was originally written by Seth Vidal and Michael Stenner, both at Duke University at the time. Since then both Michael and Seth have moved on, Seth to working for Red Hat, where he remains the dominant force behind yum development and maintenance.

[...]

Yum consists of the yum client itself as well as a suite of tools and numerous plugins that modify the basic default behavior of the yum client.

[...]

Yum can also be used as a more or less drop-in replacement for executing the familiar:

rpm -Uvh whatever.rpm


command, with the benefit that yum will automatically search its connected repositories for dependencies for the RPM at hand and permit them to be automagically installed in one step. This alone is an enormous benefit compared to trying to work one's way out of "dependency hell" and track down and install by hand all of the dependencies of a typical RPM package.

In addition, the yum client encapsulates various informational tools. It can list rpm's both installed and available for installation, extract and publish information from the rpm headers based on keywords or globs, find packages that provide particular files. Yum is therefore of great use to users of a workstation, either private or on a LAN; with yum they can look over the list of available packages to see if there is anything "interesting", search for packages that contain a particular tool or apply to a particular task, and more.

[...]

- repository: A repository is a collection of rpms under some sort of filesystem tree. For most purposes associated with yum, the repository will have two more important characteristics. It has had the command createrepo run on the tree, which extracts and encodes all of the metadata that yum relies on in order to function. Also, the tree is made accessible by URL from a server (which means as one or more of http://my.web.server/path, ftp://my.ftp.server/path, file://full/file/path to the repository tree).

[...]

- RPM: This stands for "Red Hat Package Manager", the toolset developed by Red Hat for distributing and maintaining "packages" of tools, libraries, binaries, and data for their linux distribution. It is fully open source and is currently the basis for many linux distributions other than Red Hat. When the documentation below speaks of "an rpm" it refers to a single package, usually named packagename-version.arch.rpm. To understand how yum functions, it is necessary to understand a bit about the structuring of rpm's.

An rpm consists of basically three parts: a header, a signature, and the (generally compressed) archive itself. The header contains a complete file list, a description of the package, a list of the features and libraries it provides, a list of tools it requires (from other packages) in order to function, what (known) other packages it conflicts with, and more. The basic rpm tool needs information in the header to permit a package to be installed (or uninstalled!) in such a way that:

- Installing the package breaks none of the already installed packages (recursively, as they may need packages of their own to be installed).
- All the packages that the package requires for correct operation are also (or already) installed along with the selected package, recursively.
- A later version of the package does not (accidentally) replace an earlier version of the package.

Note that a similar list applies to uninstallation; removing a package must not break any packages left behind, for example.

This process is generically known as "resolving package dependencies" and is one of the most difficult parts of package management. It is quite possible to want to install a packaged tool that requires two or three libraries and a tool. The libraries in turn may require other libraries, the tool other tools. By the time you're done, installing the package may require that you install six or eight other packages, none of which are permitted to conflict or break any of the packages that are already there or will remain behind.

If you have ever attempted to manage rpm's by hand, you know that tracking down all of the headers and dependencies and resolving all conflicts is not easy and that it actually becomes more difficult in time as a system manager updates this on one system, that on another, rebuilds a package here, installs something locally into /usr/local there. Eventually (sometimes out of sheer frustration) an rpm is --force installed, and thereafter the rpm database itself on the system itself is basically inconsistent and any rpm install is likely to fail and require --force-ing in turn. Entropy creeps into the network, and with it security risks and dysfunction.

Yet not updating packages is also a losing situation. If you leave a distribution based install untouched it remains clean. However, parts of it were likely broken at the time of install -- there are always bugs even in the most careful of major distributions. Some of those bugs are security bugs, and as crackers discover them and exploits are developed it rapidly becomes a case of "patch your system or lay out the welcome mat for vermin". This is a global problem with all operating systems; even Windows-based systems (notorious for their vulnerability to viruses and crackers) can be made reasonably secure if they are rigorously kept up to date. Finally, users come along and demand THIS package or THAT package which are crucial to their work -- but not in the original, clean, consistent installation.

In balance, any professional LAN manager (or even humble standalone linux workstation owner) has little choice; they must have some sort of mechanism for updating the packages already installed on their system(s) to the latest, patched, secure, debugged versions and for adding more packages, including ones that may not have been in the distribution they relied upon for their original base install. The only questions are: what mechanism should they use and what will it cost them (in time, hassle, learning curve, and reliability as well as in money). Let us consider the problem:

In a typical repository, there are a lot of distinct packages (currently many thousands). I have over 2500 packages installed on my Fedora 12 based laptop as I type this, corresponding to close to 1000 distinct applications. Each of these packages contains considerable metadata detailing their library requirements and so on, and can easily be as large as hundreds of megabytes in size (for the larger office suites or browsers).

Early automated update tools either required a locally mounted repository directory -- for example, the original install CD for the operating system -- in order to be able to access all of the headers quickly (local disk access even from a relatively slow CD-ROM drive, being fast enough to deliver the rpm's in a timely way so that their headers could be extracted and parsed) or required that each linked rpm be sent in its entirety over a network to an updating client from the repository just so it could read the header. The first was locally fast but required a large commitment of local disk resources (in addition to creating a new problem, that of keeping all the local copies of a master repository synchronized). The other was very slow. Both were also network resource intensive.

This is the fundamental problem that yum solves for you. Yum splits off the headers and metadata on the repository side (using createrepo or any of several other repo management tools). The headers themselves are sorted, XML encoded, and compressed, and are then available to be downloaded separately and quickly to the yum client where they are typically cached semi-permanently and periodically updated. Yum clients also cache (space permitting or according to the requirements and invocation schema selected by the system's administrator) the rpm's themselves when they are downloaded for an actual install or update, giving a yum client the best of both the options above -- a local disk image of (just the relevant part of) the repository that is automatically and transparently managed and rapid access to just the package metadata.

An actual download of all the headers associated with packages found on your system occurs the first time a yum client is invoked and thereafter it adds to or updates the cached metadata (and downloads and caches the required rpm's) only if the repository has more recent versions or if the user has deliberately invoked yum's "clean" command to empty all its caches. All of yum's dependency resolution then proceeds from these cached header files, and if for any reason the install or update requires an rpm already in the cache to be reinstalled, it is immediately available.

With the header information (only) handy on high-speed local media, the standard tools used to maintain rpm's are invoked by yum and can quickly proceed to resolve all dependencies, determine if it is safe to proceed, what additional packages need to be installed, and so forth. Note well that yum was originally designed (by a highly experienced systems administrator, Seth Vidal) with the help of all the other highly experienced systems administrators on the yum list to be safe. It will generally not proceed if it encounters a dependency loop, a package conflict, or a revision number conflict.

If yum finds that everything is good and the package can be safely installed, removed, or updated, it can either be invoked in such a way that it does so automatically with no further prompts so it can run automagically from cron, or (the general default when invoked from a command line) it can issue a user a single prompt indicating what it is about to do and requesting permission to proceed. If it finds that the requested action is in fact not safe, it will exit with as informative an error message as it can generate, permitting the system's administrator/owner to attempt to resolve the situation by hand before proceeding (which may, for example, involve removing certain conflicting packages from the client system or fixing the repository list).

From the overview given above, it should be apparent that yum is potentially a powerful tool indeed, using a single clever idea (the splitting off of the rpm headers) to achieve a singular degree of efficiency.

[...]

This HOWTO is intended to document yum's capabilities so even a novice can learn to use it client-side effectively in a very short time, and so that LAN administrators can have guidance in the necessarily more complex tasks associated with building and maintaining the repositories from which the yum clients retrieve metadata and rpm's.


1.3 Yum, RPM, and Red Hat

Because yum invokes the same tools and python bindings used by e.g. Red Hat to actually resolve dependencies and perform installations and indeed has been directly integrated into Red Hat and Fedora's original installation process for several versions now it has proven remarkably robust over several changes to the rpm toolset that have occurred since its inception, some of them fairly major. At this point it is almost impossible for yum to "break" without Red Hat's own rpm installation toolset breaking as well. Since Red Hat more or less directly supports yum development, it is most unlikely to go away or break any time soon.

It is important to emphasize, however, that yum is not a tool for administering Red Hat only repositories. Red Hat and Fedora will be prominently mentioned in this HOWTO largely because historically its original development at Duke University proceeded from the Red Hat basis for our campuswide linux distribution; Duke has been a primary (yum-enabled) mirror for Red Hat, Centos, and Fedora, and of course Duke is literally down the road a few miles from Red Hat itself.

Note Well: Yum itself is designed for, and has been successfully used to support, rpm repositories of any operating system or distribution that relies on rpm's for package management and contains or can be augmented with the requisite rpm-python tools. Yum has been tested on or is in production on just about all the major rpm-based linuces, as well as at least one Solaris repository. Its direct conceptual predecessor (with which it shares many design features and ideas, although very little remaining actual code) is Yellowdog Linux's updater tool yup, which had nothing whatsoever to do with Red Hat per se.

[...]

1.4 RPM Hell

A moment or two of meditation upon dependency resolution should suffice to convince one that Great Evil is possible in a large rpm repository. You have hundreds, perhaps thousands of rpm packages. Some are commercial, some are from some major distribution(s), others are local homebrew. What if, in all of these packages built at different times and by different people, you ever find that there exist rpm's such that (e.g.) rpm A requires rpm B, which conflicts with rpm C (already installed)? What if rpm A requires rpm B (revision 1.1.1) but rpm B (revision 1.2.1) is already installed and is required in that revision by rpm C (also already installed)? What if you install an application from source that replaces critical dependencies for installed packages that may not be compatible? What if you install a commercial package that requires an obsolete library to function? It is entirely possible to assemble an "rpm repository from hell" such that nearly any attempt to install a package will break something (or require something that breaks something).

Untangling and avoiding this mess is what earns the major (rpm-based or not) linux distribution providers whatever money they are paid. They provide an entire set of rpm's (or other packages) "all at once" that are guaranteed to be consistent in the distribution snapshot on the C'ss or ISO images or primary website repositories. All rpm's required by any rpm in the set are in the set. No rpm's in the provided set conflict with other rpm's in the set. Consequently any rpm in the set can be selected to be installed on any system built from the distribution with the confidence that, once all the rpm dependencies are resolved, the rpm (along with its missing dependencies) can be successfully installed. The set provided is at least approximately complete, so that one supposedly has little incentive or need to install packages not already in the distribution (except where so doing requires the customer to "buy" a more expensive distribution from the vendor:-).

In the real world this ideal of consistency and completeness is basically never achieved. All the distributions I've ever tried or know about have bugs, often aren't totally consistent, and certainly are not complete. A "good" distribution can serve as a base for a repository and support e.g. network installs as well as disk or CD local installs, but one must be able to add, delete, update packages new and old to the repository and distribute them to all the systems that rely on the repository for update management both automatically and on demand.

Alas, rpm itself is a terrible tool to use for this purpose, a fact that has driven managers of rpm-based systems to regularly tear their hair for years now. Using rpm directly to manage rpm installs, the most one can do is look one step ahead to try to resolve dependencies. Since dependency loops are not at all uncommon on real-world repositories where things are added and taken away (and far from unknown even in box-set linux distributions that are supposed to be dependency-loop free) one can literally chase rpm's around in loops or up a tree (so to speak;-) trying to figure out what has to be installed, uninstalled, modified, hacked, or rebuilt before finally succeeding in installing the one lonely application you originally set out to install.

rpm doesn't permit one to tell it to "install package X and anything else that it needs, after YOU figure out what that might be", nor does it know where to look for the latter. Yum, of course, does. That's why it is better!

Even yum, though, can't "fix" a dependency loop, or cope with all the arcane revision numbering schemes or dependency specifications that appear in all the rpm's one might find and rebuild or develop locally for inclusion in a central repository. When a dependency loop or other revision problem is encountered, a Real Human has to apply a considerable amount of systems expertise to resolve the problem. This suggests that building rpm's from sources in such a way that they "play nice" in a distribution repository, while also forming a critical component of said repository for other applications, is not a trivial process. So much so that many rpm developers simply do not succeed.

Also, yum achieves its greatest degree of scalability and efficiency if only rpm-based installation is permitted on all the systems using yum to keep up to date. Installing locally built software into /usr/local becomes Evil and must be prohibited (or done only by the truly knowledgeable, when truly necessary and subsequently kept up to date and maintained). Commercial packages, too, usually have to have their installation mechanisms circumvented and be repackaged into some sort of rpm for controlled distribution; this is usually a good idea anyway, as those cute little install mechanisms are often enormously stupid as they fail to replicate all of the functionality of yum and lock the system into libraries that rapidly become obsolete or that have unpatched security flaws.

For that reason, systems administrators of organizations will generally need to learn how to build rpms and set up local organization-specific repositories to handle packages that are not already built and available in the base distribution. An entire section of this HOWTO is devoted to a guide for repository maintainers and rpm builders, including some practices which (if followed) would make dependency and revision numbering problems far less common and life consequently good.

In the next few sections we will see where to get yum (if it isn't already the basis of your operating system environment, how to install its server side support including a small repository, and then how to set up and test a yum client. Following that there will be a few sections on advanced topics and design issues; how to set up a repository in a complex environment, how to build rpm's that are relatively unlikely to create dependency and revision problems in a joint repository, how to package third party (e.g. site licensed) software so it can be distributed, updated, and maintained via yum (linux software distributors take note!) and more.




Hm.


Ok. Managing the software stack on a computer is clearly a major problem.

RPM appears to have originally stood for "Red Hat Package Manager" but has now become a recursive acronym for "RPM Package Manager".

I note that:
- RPM was the original tool for managing .rpm packages. The package format and the RPM package manager were built at Red Hat.
- Yum descends philosophically from Yellowdog Linux's updater tool yup but was rebuilt to process .rpm packages.
- RPM could only look one step ahead in the dependency tree for a particular package. Yum can perform recursive dependency resolution.
- The main insight of yum was to split off the package headers, so that they could be downloaded and analysed separately, allowing dependency resolution without downloading or processing the entirety of each dependency package.


Future question: Is there a second, separate signature for a package header? If so, the dependency tree could be constructed/resolved from the signed package headers before downloading any large dependencies (whose signatures would then also need to be checked).



Ok.


Do yum and/or rpm exist on the Centos 6.9 Minimal? Given the focus on package management in the excerpt above, and the role of Red Hat, I'd be surprised if they didn't.


aineko:Downloads stjohnpiano$ grep yum available_tools_on_centos_69_minimal.txt

yum

aineko:Downloads stjohnpiano$ grep rpm available_tools_on_centos_69_minimal.txt

rpm
rpm2cpio
rpmdb
rpmquery
rpmsign
rpmverify



Good.


Let's try this approach:
- download centos gcc .rpm package.
- use a memory stick to move the package to Kalkin.
- can yum be used to check a package signature before installation?
-- where do I find the key for the particular repository from which I downloaded the package?
-- where do I put a key so that yum can see it?
-- if yum can't check signatures, try rpmverify.
- can yum be used to list the dependencies of a package before installation?

Next:
- given a group of .rpm packages in a directory, can yum perform recursive dependency resolution, and report whether or not the entire dependency tree successfully resolves (without installing anything)?

Also: Presumably the package header contains the destination filesystem location for each file that it contains. Can yum be used to list each file in a .rpm package and its designated target location?



Ok.

I'm going to assume that the main GCC rpm package is this one:
gcc-4.4.7-18.el6.x86_64.rpm

Download it from:
mirror.centos.org/centos/6/os/x86_64/Packages
by clicking its name, which is a link.

Copy it onto a memory stick (HP, 32 GB).

Ideally, if I attempt to use yum to install the gcc rpm, yum will stop and report a list of missing dependencies.


Is the
man
documentation tool available on Kalkin?

aineko:Downloads stjohnpiano$ grep man available_tools_on_centos_69_minimal.txt

command


Nope.


Move over to Kalkin:

Insert memory stick.


[root@kalkin work]#
sd 5:0:0:0: [sdg] Assuming drive cache: write through
sd 5:0:0:0: [sdg] Assuming drive cache: write through
sd 5:0:0:0: [sdg] Assuming drive cache: write through


Output hangs. Press enter. New prompt appears.


[root@kalkin ~]# blkid

/dev/sda1: UUID="e0b18dd5-f392-42ca-bbf1-89a1a0229e38" TYPE="ext4"
/dev/sda2: UUID="rWbUY4-wwiQ-J2Vp-n0F5-bngF-G8yb-HWQyEv" TYPE="LVM2_member"
/dev/mapper/vg_kalkin-lv_root: UUID="508692c4-54da-4a93-b2e2-6f1584e74afe" TYPE="ext4"
/dev/mapper/vg_kalkin-lv_swap: UUID="707ee542-6bfe-453d-b43c-bcfc58c59b6f" TYPE="swap"
/dev/mapper/vg_kalkin-lv_home: UUID="6134733c-158e-4d62-a74d-e7d00e2ed8fd" TYPE="ext4"
/dev/sdg1: LABEL="HP v150w" UUID="81A8-0559" TYPE="vfat"

[root@kalkin ~]# ls -1 /mnt

test1

[root@kalkin ~]# ls -1 /mnt/test1


[root@kalkin work]# mount /dev/sdg1 /mnt/test1


[root@kalkin ~]# ls -1 /mnt/test1

gcc-4.4.7-18.el6.x86_64.rpm

[root@kalkin ~]# mkdir /home/work/rpms


[root@kalkin ~]# cp /mnt/test1/gcc-4.4.7-18.el6.x86_64.rpm /home/work/rpms/


[root@kalkin ~]# ls /home/work/rpms

gcc-4.4.7-18.el6.x86_64.rpm



Ok, workspace is set up.


Let's have a look at yum. Note: Kalkin is not currently connected to the local network.


[root@kalkin ~]# yum --version

3.2.29 Installed: rpm-4.8.0-55.el6.x86_64 at 2018-01-03 23:50 Built : CentOS BuildSystem <http://bugs.centos.org> at 2016-05-10 23:49 Committed: Lubos Kardos <lkardos@redhat.com> at 2016-03-29 Installed: yum-3.2.29-81.el6.centos.noarch at 2018-01-03 23:50 Built : CentOS BuildSystem <http://bugs.centos.org> at 2017-03-22 05:32 Committed: Johnny Hughes <johnny@centos.org> at 2017-03-21 Installed: yum-plugin-fastestmirror-1.1.30-40.el6.noarch at 2018-01-03 23:50 Built : CentOS BuildSystem <http://bugs.centos.org> at 2017-03-22 04:49 Committed: Valentina Mukhamedzhanova <vmukhame@redhat.com> at 2016-11-25



Why is rpm listed in
yum --version
output?


Google "how yum works".


Excerpts from:
www.redhat.com/archives/rhl-list/2008-January/msg02246.html
Author: Michael Schwendt
Date: 16 Jan 2008

Re: How does yum work ??

From: "Michael Schwendt" <mschwendt gmail com>
To: "For users of Fedora" <fedora-list redhat com>
Subject: Re: How does yum work ??
Date: Wed, 16 Jan 2008 14:41:02 +0100

[...]

The interaction between Yum, package metadata and RPM should be fairly obvious. Yum accesses local or remote repositories, which usually are normal http/ftp servers that contain RPM packages plus the corresponding metadata archives generated by the createrepo tool. The metadata describe the available packages beyond the information available in the filenames and without the need to download full packages. Basically, many data from a file's RPM package header (such as name, epoch, version, release, arch, excludearch and exlusivearch lists, dependency details, package capabilities, virtual package names, library SONAMEs, obsoletes, conflict definitions, but also filelists) are copied into the metadata archives, but in a format that is more convenient and faster to parse, e.g. xml or sqlite files. Having learned what packages are available in the repositories, Yum queries the local RPM database to examine what packages are installed already. Combining the information it is able to determine what newer packages are available as updates which is Yum's primary purpose. Since updates can also replace other packages or require new packages to be added, there's quite some time spent on processing and resolving lots of package metadata. For any packages to be installed, it either downloads them via the network or accesses them locally. It then uses the RPM library to examine a transaction set of packages further in order to find out whether there are any dependency problems or conflicts before asking RPM to perform a transaction. That's only a very brief coverage of what Yum does.


Key sections:
- Yum "queries the local RPM database to examine what packages are installed already."
- Yum "uses the RPM library to examine a transaction set of packages further in order to find out whether there are any dependency problems or conflicts before asking RPM to perform a transaction."

So yum depends on rpm.



Well, I'll investigate the available yum commands, and see what happens.

I'll use
script
to record the output, and I'll add it to this log after recovering it.

Note: I have found that the output of
script
can be inaccurate and is sometimes nearly useless. It should be used with caution, especially if you are trying to record the output of commands that cause a filesystem change and whose output will therefore be different if run again. Ideally, you should retain the output on the original screen, transfer the
script
output to the work computer, and then correct it while the original output can still be viewed.



[root@kalkin ~]# cd /home/work


[root@kalkin work]# ls -1

bible.txt
hello.txt
rpms

[root@kalkin work]# script screen.log

Script started, file is screen.log

[root@kalkin work]# yum --help

[output omitted]

[root@kalkin work]# exit

Script done, file is screen.log

[root@kalkin work]# cp screen.log /mnt/test1/


[root@kalkin work]# umount /mnt/test1/



Remove the memory stick from Kalkin.

Insert it into Aineko. It mounts automatically and an icon appears on the Desktop.

Copy the screen.log file to ~/Downloads.

On opening the file in TextWrangler, I see extra newlines.


While listing available tools on Centos 6.9 Minimal, I learned how to remove any additional carriage return bytes ("\r") produced by
script
.

aineko:Downloads stjohnpiano$ wc -c screen.log

3923 screen.log

aineko:Downloads stjohnpiano$ tr -cd "\r" < screen.log | wc -c

81

aineko:Downloads stjohnpiano$ tr -d "\r" < screen.log | wc -c

3842

aineko:Downloads stjohnpiano$ tr -d "\r" < screen.log > screen2.log


aineko:Downloads stjohnpiano$ wc -c screen2.log

3842 screen2.log



screen.log originally contained 3923 bytes. 81 "\r" bytes were removed to produce screen2.log, which contains 3842 bytes.



Now that I have demonstrated
- how
script
can record command output
- how to mount/unmount a memory stick
- recovering and formatting the log produced by
script

I won't record the use of these items during the rest of this log.



screen2.log
Script started on Mon 12 Mar 2018 06:40:17 PM GMT [root@kalkin work]# yum --help Loaded plugins: fastestmirror Usage: yum [options] COMMAND List of Commands: check Check for problems in the rpmdb check-update Check for available package updates clean Remove cached data deplist List a package's dependencies distribution-synchronization Synchronize installed packages to the latest available versions downgrade downgrade a package erase Remove a package or packages from your system groupinfo Display details about a package group groupinstall Install the packages in a group on your system grouplist List available package groups groupremove Remove the packages in a group from your system help Display a helpful usage message history Display, or use, the transaction history info Display details about a package or group of packages install Install a package or packages on your system list List a package or groups of packages load-transaction load a saved transaction from filename makecache Generate the metadata cache provides Find what package provides the given value reinstall reinstall a package repolist Display the configured software repositories resolvedep Determine which package provides the given dependency search Search package details for the given string shell Run an interactive yum shell update Update a package or packages on your system upgrade Update packages taking obsoletes into account version Display a version for the machine and/or available repos. Options: -h, --help show this help message and exit -t, --tolerant be tolerant of errors -C, --cacheonly run entirely from system cache, don't update cache -c [config file], --config=[config file] config file location -R [minutes], --randomwait=[minutes] maximum command wait time -d [debug level], --debuglevel=[debug level] debugging output level --showduplicates show duplicates, in repos, in list/search commands -e [error level], --errorlevel=[error level] error output level --rpmverbosity=[debug level name] debugging output level for rpm -q, --quiet quiet operation -v, --verbose verbose operation -y, --assumeyes answer yes for all questions --assumeno answer no for all questions --version show Yum version and exit --installroot=[path] set install root --enablerepo=[repo] enable one or more repositories (wildcards allowed) --disablerepo=[repo] disable one or more repositories (wildcards allowed) -x [package], --exclude=[package] exclude package(s) by name or glob --disableexcludes=[repo] disable exclude from main, for a repo or for everything --obsoletes enable obsoletes processing during updates --noplugins disable Yum plugins --nogpgcheck disable gpg signature checking --disableplugin=[plugin] disable plugins by name --enableplugin=[plugin] enable plugins by name --skip-broken skip packages with depsolving problems --color=COLOR control whether color is used --releasever=RELEASEVER set value of $releasever in yum config and repo files --downloadonly don't update, just download --downloaddir=DLDIR specifies an alternate directory to store packages --setopt=SETOPTS set arbitrary config and repo options Plugin Options: [root@kalkin work]# exit exit Script done on Mon 12 Mar 2018 06:42:33 PM GMT




Ok.


Switch back to Kalkin.


[root@kalkin work]# yum check

Loaded plugins: fastestmirror
check all

[root@kalkin work]# yum history

Loaded plugins: fastestmirror
Loaded plugins: fastestmirror ID | Login user | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 1 | System <unset> | 2018-01-03 23:49 | Install | 205

history list

[root@kalkin work]# yum info rpms/gcc-4.4.7-18.el6.x86_64.rpm

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os&infra=stock error was
14: PYCURL ERROR 6 - "Couldn't resolve host 'mirrorlist.centos.org'"
Error: Cannot find a valid baseurl for repo: base

[root@kalkin work]# yum list rpms/gcc-4.4.7-18.el6.x86_64.rpm

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os&infra=stock error was
14: PYCURL ERROR 6 - "Couldn't resolve host 'mirrorlist.centos.org'"
Error: Cannot find a valid baseurl for repo: base

[root@kalkin work]# yum clean

Error: clean requires an option: headers, packages, metadata, dbcache, plugins, expire-cache, rpmdb, all

[root@kalkin work]# yum deplist rpms/gcc-4.4.7-18.el6.x86_64.rpm

Loaded plugins: fastestmirror
Finding dependencies:
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
Error: Could not open local rpm file: rpms/gcc-4.4.7-18.el6.x86_64.rpm: RPM Error opening Package

[root@kalkin work]# yum repolist

Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os&infra=stock error was 14: PYCURL ERROR 6 - "Couldn't resolve host 'mirrorlist.centos.org'" Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=extras&infra=stock error was 14: PYCURL ERROR 6 - "Couldn't resolve host 'mirrorlist.centos.org'" Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=updates&infra=stock error was 14: PYCURL ERROR 6 - "Couldn't resolve host 'mirrorlist.centos.org'" repo id repo name status base CentOS-6 - Base 0 extras CentOS-6 - Extras 0 updates CentOS-6 - Updates 0 repolist: 0


[root@kalkin work]# yum clean all

Loaded plugins: fastestmirror
Cleaning repos: base extras updates
Cleaning up Everything
Cleaning up list of fastest mirrors

[root@kalkin work]# yum --nogpgcheck deplist rpms/gcc-4.4.7-18.el6.x86_64.rpm

Loaded plugins: fastestmirror
Finding dependencies:
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
Error: Could not open local rpm file: rpms/gcc-4.4.7-18.el6.x86_64.rpm: RPM Error opening Package




Looking at this output, I realise that I had assumed that although rpm package headers are split off and accessible separately, the rpm package itself would still contain a copy of the headers. Assuming this to be true, yum is apparently designed to ask a repository for the headers instead of looking into the package, even when targeted at a package file.

I'm surprised that running
yum info
and
yum deplist
produced no information about the package. I'm glad that
yum deplist
warns me that it doesn't have the signing key, but the error immediately afterwards implies that it needs the signing key in order to look at the package, which I find strange. Signed items can still be read (if they're not encrypted).

I'll try some more things, but it looks to me as though yum wants to see and talk to a repository, and doesn't like being asked to look at an individual package file. This suggests a new approach: Create a repository (containing all the dependencies for gcc, according to an existing repository) on another Centos computer, transfer it to Kalkin via a memory stick, and see if yum can be made to target an offline repository stored on the filesystem.


First, let's try disabling the current repositories, found from the output of
yum repolist
.

list:
- base (CentOS-6 - Base)
- extras (CentOS-6 - Extras)
- updates (CentOS-6 - Updates)

I'll try using
yum --disablerepo=[repo]
.


[root@kalkin work]# yum --disablerepo=base

[result: the same output as yum --help]

[root@kalkin work]# yum --disablerepo base

[result: the same output as yum --help]

[root@kalkin work]# yum --disablerepo "CentOS-6 - Base"

Loaded plugins: fastestmirror
Error getting repository data for CentOS-6 - Base, repository not found



I suspect that the
--disablerepo
option is used to temporarily disable a repository while running a yum command, not to permanently disable a repository when used by itself.


Google "yum disable repo".

Excerpts from:
access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-managing_yum_repositories

8.4.5. ADDING, ENABLING, AND DISABLING A YUM REPOSITORY

[...]

This section explains how to add, enable, and disable a repository by using the
yum-config-manager
command.

[...]

Adding a Yum Repository

To define a new repository, you can either add a
[repository]
section to the
/etc/yum.conf
file, or to a
.repo file
in the
/etc/yum.repos.d/
directory. All files with the
.repo
file extension in this directory are read by
yum
, and it is recommended to define your repositories here instead of in
/etc/yum.conf
.

Warning

Obtaining and installing software packages from unverified or untrusted software sources other than Red Hat Network constitutes a potential security risk, and could lead to security, stability, compatibility, and maintainability issues.

[...]

To enable a particular repository or repositories, type the following at a shell prompt as root:

yum-config-manager --enable repository


where repository is the unique repository ID (use
yum repolist all
to list available repository IDs).



aineko:Downloads stjohnpiano$ grep yum* available_tools_on_centos_69_minimal.txt

yum



yum-config-manager is not included in Centos 6.9 Minimal.


But yum-config-manager is just an interface for accessing yum's config files, which I can do manually.

[root@kalkin work]# ls -1 /etc/yum*

/etc/yum.conf

/etc/yum:
pluginconf.d
protected.d
vars
version-groups.conf

/etc/yum.repos.d:
CentOS-6-Base.repo
CentOS-6-Debuginfo.repo
CentOS-6-fasttrack.repo
CentOS-6-Media.repo
CentOS-6-Vault.repo




I'll now copy the contents of some of these config files into this log. Rather than use
script
to record output printed on the terminal, I can just copy the files to the memory stick.

[root@kalkin work]# cp /etc/yum.conf /mnt/test1/


[root@kalkin work]# cp -r /etc/yum.repos.d /mnt/test1/




On Aineko:


aineko:Downloads stjohnpiano$ cd /Volumes/HP\ v150w/


aineko:HP v150w stjohnpiano$ ls -1

gcc-4.4.7-18.el6.x86_64.rpm
screen.log
yum.conf
yum.repos.d


aineko:HP v150w stjohnpiano$ cat yum.conf

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=5
bugtracker_url=http://bugs.centos.org/set_project.php?project_id=19&ref=http://bugs.centos.org/bug_report_page.php?category=yum
distroverpkg=centos-release

# This is the default, if you make this bigger yum won't see if the metadata
# is newer on the remote and so you'll "gain" the bandwidth of not having to
# download the new metadata and "pay" for it by yum not having correct
# information.
# It is esp. important, to have correct metadata, for distributions like
# Fedora which don't keep old packages around. If you don't like this checking
# interupting your command line usage, it's much better to have something
# manually check the metadata once an hour (yum-updatesd will do this).
# metadata_expire=90m

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d



Hm. Nothing in yum.conf seems to be used to enable/disable repos.

I note
gpgcheck=1
, which probably tells yum to use gpgcheck by default.

Key section:
# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d


aineko:HP v150w stjohnpiano$ ls -1 yum.repos.d

CentOS-Base.repo
CentOS-Debuginfo.repo
CentOS-Media.repo
CentOS-Vault.repo
CentOS-fasttrack.repo


aineko:HP v150w stjohnpiano$ cat yum.repos.d/CentOS-Base.repo

# CentOS-Base.repo
#
# The mirror system uses the connecting IP address of the client and the
# update status of each mirror to pick mirrors that are updated to and
# geographically close to the client. You should use this for CentOS updates
# unless you are manually picking other mirrors.
#
# If the mirrorlist= does not work for you, as a fall back you can try the
# remarked out baseurl= line instead.
#
#

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

#contrib - packages by Centos Users
[contrib]
name=CentOS-$releasever - Contrib
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6



Comments:
- All five items expect to find a key stored at
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
.
- I'm unsure whether these five items are meant to be separate repositories that all share the same key, or whether they're considered to be pieces of a single repository (since they're all in the same .repo file).
-- This section "PUT YOUR REPOS HERE OR IN separate files named file.repo" persuades me that each item is a repository. The repositories in CentOS-Base.repo all use the same key.
-
enabled=0
is used on the last two items, which is probably why they didn't appear when I ran e.g.
yum repolist
.
- I can probably use
enabled=0
to disable the first three items.
-
gpgcheck=1
exists in every repository here, which might indicate that its existence in the yum.conf file does not have any effect on whether the repositories in the .repo files use gpgcheck.
- The repo id is set by using square brackets [] and (apart from comments) it is the first line in a repository. The end of a repository is apparently set by using a blank line.


aineko:Downloads stjohnpiano$ cat yum.repos.d/CentOS-Media.repo

# CentOS-Media.repo # # This repo can be used with mounted DVD media, verify the mount point for # CentOS-6. You can use this repo and yum to install items directly off the # DVD ISO that we release. # # To use this repo, put in your DVD and use it with the other repos too: # yum --enablerepo=c6-media [command] # # or for ONLY the media repo, do this: # # yum --disablerepo=\* --enablerepo=c6-media [command] [c6-media] name=CentOS-$releasever - Media baseurl=file:///media/CentOS/ file:///media/cdrom/ file:///media/cdrecorder/ gpgcheck=1 enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6



I might be able to use this CentOS-Media.repo file as a starting point for writing a .repo file for a repository copied onto the filesystem.


I need a text editor on Kalkin.

aineko:Downloads stjohnpiano$ grep nano available_tools_on_centos_69_minimal.txt


aineko:Downloads stjohnpiano$ grep ed available_tools_on_centos_69_minimal.txt

genhomedircon
localedef
lvreduce
mkhomedir_helper
sed
sedismod
sedispol
selinuxenabled
setleds
shred
sudoedit
vgreduce

aineko:Downloads stjohnpiano$ grep vi available_tools_on_centos_69_minimal.txt

auvirt
grodvi
pluginviewer
rvi
rview
service
vi
view
vigr
vipw
visudo


vi is available.



Let's look at basic
vi
commands.

The following material originally came from:
www.cs.colostate.edu/helpdocs/vi.html
and has been edited.

# WHAT IS VI?

The default editor that comes with the UNIX operating system is called vi (visual editor).

The UNIX vi editor is a full screen editor and has two modes of operation:
- Command mode commands which cause action to be taken on the file, and
- Insert mode in which entered text is inserted into the file.

In the command mode, every character typed is a command that does something to the text file being edited; a character typed in the command mode may even cause the vi editor to enter the insert mode. In the insert mode, every character typed is added to the text in the file; pressing the [Esc] (Escape) key turns off the Insert mode.


# NOTES

The cursor moves to the bottom of the screen whenever a colon (:) is typed. This type of command is completed by hitting the Return (or Enter) key.

The symbol ^ before a letter means that the [Ctrl] key should be held down while the letter key is pressed.


# TO GET INTO AND OUT OF VI

[open file for editing]
$ vi [filepath]

[quit vi, writing out modified file to file named in original invocation]
:x[Return]

[quit vi, writing out modified file to file named in original invocation]
:wq[Return]

[quit (or exit) vi]
:q[Return]

[quit vi even though latest changes have not been saved for this vi call]
:q![Return]


# MOVING THE CURSOR

On some UNIX platforms, the arrow keys may be used; however, since vi was designed with the Qwerty keyboard (containing no arrow keys) in mind, the arrow keys sometimes produce strange effects in vi and should be avoided.

[move cursor down one line]
j or [Return] or down-arrow

[move cursor up one line]
k or up-arrow

[move cursor left one character]
h or [Backspace] or left-arrow

[move cursor right one character]
l or [Space] or right-arrow

[move cursor to start of current line (the one with the cursor)]
0 [zero]

[move cursor to end of current line]
$

[move cursor to beginning of next word]
w

[move cursor back to beginning of preceding word]
b

[move cursor to first line in file]
:0[Return] or 1G

[move cursor to line n]
:n[Return] or nG

[move cursor to last line in file]
:$[Return] or G


# SCREEN MANIPULATION

The following commands allow the vi editor screen (or window) to move up or down several lines and to be refreshed.

[move forward one screen]
^f

[move backward one screen]
^b

[move down (forward) one half screen]
^d

[move up (back) one half screen]
^u

[redraws the screen]
^l

[redraws the screen, removing deleted lines]
^r


# ADDING, CHANGING, AND DELETING TEXT

The main purpose of an editor is to create, add, or modify text for a file.

Perhaps the most important command is the one that allows you to back up and undo your last action. Unfortunately, this command acts like a toggle, undoing and redoing your most recent action. You cannot go back more than one step.

[UNDO WHATEVER YOU JUST DID; a simple toggle]
u


## INSERTING OR ADDING TEXT

The following commands allow you to insert and add text. Each of these commands puts the vi editor into insert mode; thus, the [Esc] key must be pressed to terminate the entry of text and to put the vi editor back into command mode.

[insert text before cursor, until [Esc] hit]
i

[insert text at beginning of current line, until [Esc] hit]
I

[append text after cursor, until [Esc] hit]
a

[append text to end of current line, until [Esc] hit]
A

[open and put text in a new line below current line, until [Esc] hit]
o

[open and put text in a new line above current line, until [Esc] hit]
O


## CHANGING TEXT

The following commands allow you to modify text.

[replace single character under cursor (no [Esc] needed)]
r

[replace characters, starting with current cursor position, until [Esc] hit]
R

[change the current word with new text, starting with the character under cursor, until [Esc] hit]
cw

[change N words beginning with character under cursor, until [Esc] hit; e.g., c5w changes 5 words]
cNw

[change (replace) the characters in the current line, until [Esc] hit]
C

[change (replace) the entire current line, stopping when [Esc] is hit]
cc

[change (replace) the next N lines, starting with the current line, stopping when [Esc] is hit]
Ncc or cNc


## DELETING TEXT

The following commands allow you to delete text.

[delete single character under cursor]
x

[delete N characters, starting with character under cursor]
Nx

[delete the single word beginning with character under cursor]
dw

[delete N words beginning with character under cursor; e.g., d5w deletes 5 words]
dNw

[delete the remainder of the line, starting with current cursor position]
D

[delete entire current line]
dd

[delete N lines, beginning with the current line; e.g., 5dd deletes 5 lines]
Ndd or dNd


## CUTTING AND PASTING TEXT

The following commands allow you to copy and paste text.

[copy (yank, cut) the current line into the buffer]
yy

[copy (yank, cut) the next N lines, including the current line, into the buffer]
Nyy or yNy

[put (paste) the line(s) in the buffer into the text after the current line]
p


# OTHER COMMANDS


## SEARCHING TEXT

A common occurrence in text editing is to replace one word or phase by another. To locate instances of particular sets of characters (or strings), use the following commands.

[search forward for occurrence of string in text]
/string

[search backward for occurrence of string in text]
?string

[move to next occurrence of search string]
n

[move to next occurrence of search string in opposite direction]
N


## DETERMINING LINE NUMBERS

Being able to determine the line number of the current line or the total number of lines in the file being edited is sometimes useful.

[returns line number of current line at bottom of screen]
:.=

[returns the total number of lines at bottom of screen]
:=

[provides the current line number, along with the total number of lines, in the file at the bottom of the screen]
^g


# SAVING AND READING FILES

These commands permit you to input and output files other than the named file with which you are currently working.

[read file named "filename" and insert after current line (the line with cursor)]
:r filename[Return]

[write current contents to file named in original vi call]
:w[Return]

[write current contents to a new file named "newfile"]
:w newfile[Return]

[write the contents of the lines numbered 12 through 35 to a new file named "smallfile"]
:12,35w smallfile[Return]

[write current contents over a pre-existing file named "prevfile"]
:w! prevfile[Return]



Switch back to Kalkin.

Use
vi
to open the file
/etc/yum.repos.d/CentOS-6-Base.repo
for editing. For each of the first three items, add the line "enabled=0" after the line "gpgcheck=1".


Next: Check that the three repositories have been disabled.

[root@kalkin work]# yum info rpms/gcc-4.4.7-18.el6.x86_64.rpm

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Error: No matching Packages to list

[root@kalkin work]# yum list rpms/gcc-4.4.7-18.el6.x86_64.rpm

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Error: No matching Packages to list

[root@kalkin work]# yum deplist rpms/gcc-4.4.7-18.el6.x86_64.rpm

Loaded plugins: fastestmirror
Finding dependencies:
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
Error: Could not open local rpm file: rpms/gcc-4.4.7-18.el6.x86_64.rpm: RPM Error opening Package

[root@kalkin work]# yum repolist

Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile repolist: 0


[root@kalkin work]# yum --nogpgcheck deplist rpms/gcc-4.4.7-18.el6.x86_64.rpm

Loaded plugins: fastestmirror
Finding dependencies:
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
Error: Could not open local rpm file: rpms/gcc-4.4.7-18.el6.x86_64.rpm: RPM Error opening Package



Good.



Next, I'd like yum to have the Centos key available.

In the .repo file, the key location was:
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6


I could copy the key file to this location manually. However, there is probably an import pipeline. It would be better to use this pipeline, in case metadata is created during the import.



Some reading indicates that:
- yum relies on rpm's key management system. This makes sense, given that "rpm-gpg" appears in the key location string but "yum" does not.
- The command to import a key into rpm is
rpm --import [path_to_key]
.
- Some repositories include a special package that contains the repository key and the repository .repo file, along with code that installs them.




Ok. I'll investigate rpm.


I'd like to see if there is another way (besides using
script
) to display the output of a command and simultaneously record this output.


Google "linux send output to file and screen".


Excerpt from:
stackoverflow.com/questions/418896/how-to-redirect-output-to-a-file-and-stdout

Q:

How to redirect output to a file and stdout

In bash, calling
foo
would display any output from that command on the stdout.

Calling
foo > output
would redirect any output from that command to the file specified (in this case 'output').

Is there a way to redirect output to a file and have it display on stdout?

edited Jun 19 '14 at 7:56
Mike

asked Jan 7 '09 at 1:45
SCdF


A:

The command you want is named
tee
:

foo | tee output.file


For example, if you only care about stdout:

ls -a | tee output.file


If you want to include stderr, do:

program [arguments...] 2>&1 | tee outfile


2>&1
redirects channel 2 (stderr/standard error) into channel 1 (stdout/standard output), such that both is written as stdout. It is also directed to the given output file as of the
tee
command.

Furthermore, if you want to append to the log file, use
tee -a
as:

program [arguments...] 2>&1 | tee -a outfile


edited Oct 23 '17 at 17:10
gustafbstrom

answered Jan 7 '09 at 1:48
Zoredache



Key section:
program [arguments...] 2>&1 | tee -a outfile


This should display both output and error messages and append these to a storage file.


aineko:Downloads stjohnpiano$ grep tee available_tools_on_centos_69_minimal.txt

tee


It's available.


Switch to Kalkin.



[root@kalkin work]# ls -1

archived
rpms
screen.log

[root@kalkin work]# echo "hello" | tee -a hello.log

hello

[root@kalkin work]# ls -1

archived
hello.log
rpms
screen.log

[root@kalkin work]# cat hello.log

hello

[root@kalkin work]# rm hello.log

rm: remove regular file 'hello.log'? y



[command] | tee -a [filename]
works as expected.

Note: It doesn't record the command itself, only the output. This can be worked around by echoing the command to the log file before running it. Use the
-e
flag for the
echo
command to interpret backslash-escaped newline characters.

The output of the following four commands is omitted.

[root@kalkin work]# echo -e "\n\nCOMMAND# rpm --version\n" | tee -a work.log


[root@kalkin work]# rpm --version | tee -a work.log


[root@kalkin work]# echo -e "\n\nCOMMAND# rpm --help\n" | tee -a work.log


[root@kalkin work]# rpm --help | tee -a work.log



Use a memory stick to transfer work.log from Kalkin to Aineko.


work.log
COMMAND# rpm --version RPM version 4.8.0 COMMAND# rpm --help Usage: rpm [OPTION...] --quiet Query/Verify package selection options: -a, --all query/verify all packages -f, --file query/verify package(s) owning file -g, --group query/verify package(s) in group -p, --package query/verify a package file -W, --ftswalk query/verify package(s) from TOP file tree walk --pkgid query/verify package(s) with package identifier --hdrid query/verify package(s) with header identifier --fileid query/verify package(s) with file identifier --specfile query a spec file --triggeredby query the package(s) triggered by the package --whatrequires query/verify the package(s) which require a dependency --whatprovides query/verify the package(s) which provide a dependency --nomanifest do not process non-package files as manifests Query options (with -q or --query): -c, --configfiles list all configuration files -d, --docfiles list all documentation files --dump dump basic file information -l, --list list files in package --queryformat=QUERYFORMAT use the following query format -s, --state display the states of the listed files Verify options (with -V or --verify): --nofiledigest don't verify digest of files --nomd5 don't verify digest of files --nofiles don't verify files in package --nodeps don't verify package dependencies --noscript don't execute verify script(s) File tree walk options (with --ftswalk): --comfollow follow command line symlinks --logical logical walk --nochdir don't change directories --nostat don't get stat info --physical physical walk --seedot return dot and dot-dot --xdev don't cross devices --whiteout return whiteout information Signature options: --addsign sign package(s) (identical to --resign) -K, --checksig verify package signature(s) --delsign delete package signatures --import import an armored public key --resign sign package(s) (identical to --addsign) --nodigest don't verify package digest(s) --nosignature don't verify package signature(s) Database options: --initdb initialize database --rebuilddb rebuild database inverted lists from installed package headers Install/Upgrade/Erase options: --aid add suggested packages to transaction --allfiles install all files, even configurations which might otherwise be skipped --allmatches remove all packages which match <package> (normally an error is generated if <package> specified multiple packages) --badreloc relocate files in non-relocatable package -e, --erase=<package>+ erase (uninstall) package --excludedocs do not install documentation --excludepath=<path> skip files with leading component <path> --fileconflicts detect file conflicts between packages --force short hand for --replacepkgs --replacefiles -F, --freshen=<packagefile>+ upgrade package(s) if already installed -h, --hash print hash marks as package installs (good with -v) --ignorearch don't verify package architecture --ignoreos don't verify package operating system --ignoresize don't check disk space before installing -i, --install install package(s) --justdb update the database, but do not modify the filesystem --nodeps do not verify package dependencies --nofiledigest don't verify digest of files --nomd5 don't verify digest of files (obsolete) --nocontexts don't install file security contexts --noorder do not reorder package installation to satisfy dependencies --nosuggest do not suggest missing dependency resolution(s) --noscripts do not execute package scriptlet(s) --notriggers do not execute any scriptlet(s) triggered by this package --oldpackage upgrade to an old version of the package (--force on upgrades does this automatically) --percent print percentages as package installs --prefix=<dir> relocate the package to <dir>, if relocatable --relocate=<old>=<new> relocate files from path <old> to <new> --replacefiles ignore file conflicts between packages --replacepkgs reinstall if the package is already present --test don't install, but tell if it would work or not -U, --upgrade=<packagefile>+ upgrade package(s) Common options for all rpm modes and executables: -D, --define='MACRO EXPR' define MACRO with value EXPR -E, --eval='EXPR' print macro expansion of EXPR --macros=<FILE:...> read <FILE:...> instead of default file(s) --nodigest don't verify package digest(s) --nosignature don't verify package signature(s) --rcfile=<FILE:...> read <FILE:...> instead of default file(s) -r, --root=ROOT use ROOT as top level directory (default: "/") --querytags display known query tags --showrc display final rpmrc and macro configuration --quiet provide less detailed output -v, --verbose provide more detailed output --version print the version of rpm being used Options implemented via popt alias/exec: --scripts list install/erase scriptlets from package(s) --setperms set permissions of files in a package --setugids set user/group ownership of files in a package --conflicts list capabilities this package conflicts with --obsoletes list other packages removed by installing this package --provides list capabilities that this package provides --requires list capabilities required by package(s) --info list descriptive information from package(s) --changelog list change logs for this package --xml list metadata in xml --triggers list trigger scriptlets from package(s) --last list package(s) by install time, most recent first --dupes list duplicated packages --filesbypkg list all files from each package --fileclass list file names with classes --filecolor list file names with colors --fscontext list file names with security context from file system --fileprovide list file names with provides --filerequire list file names with requires --filecaps list file names with POSIX1.e capabilities Help options: -?, --help Show this help message --usage Display brief usage message



During the rest of this project, I won't record my use of
[command] | tee -a [filename]
to store output and transfer it to this log.


The
--import
flag ("import an armored public key") appears to be the correct lever to pull for importing the Centos key.

I don't see a flag for testing the validity of the format of the key file before trying to import it.

I'd like to list all keys that are already in rpm key management system.



[root@kalkin work]# rpm --usage

Usage: rpm [-aKfgpWHqVcdilsKiv?] [-a|--all] [-f|--file] [-g|--group] [-p|--package] [-W|--ftswalk] [--pkgid] [--hdrid] [--fileid] [--specfile] [--triggeredby] [--whatrequires] [--whatprovides] [--nomanifest] [-c|--configfiles] [-d|--docfiles] [--dump] [-l|--list] [--queryformat=QUERYFORMAT] [-s|--state] [--nofiledigest] [--nomd5] [--nofiles] [--nodeps] [--noscript] [--comfollow] [--logical] [--nochdir] [--nostat] [--physical] [--seedot] [--xdev] [--whiteout] [--addsign] [-K|--checksig] [--delsign] [--import] [--resign] [--nodigest] [--nosignature] [--initdb] [--rebuilddb] [--aid] [--allfiles] [--allmatches] [--badreloc] [-e|--erase <package>+] [--excludedocs] [--excludepath=<path>] [--fileconflicts] [--force] [-F|--freshen <packagefile>+] [-h|--hash] [--ignorearch] [--ignoreos] [--ignoresize] [-i|--install] [--justdb] [--nodeps] [--nofiledigest] [--nomd5] [--nocontexts] [--noorder] [--nosuggest] [--noscripts] [--notriggers] [--oldpackage] [--percent] [--prefix=<dir>] [--relocate=<old>=<new>] [--replacefiles] [--replacepkgs] [--test] [-U|--upgrade <packagefile>+] [--quiet] [-D|--define 'MACRO EXPR'] [-E|--eval 'EXPR'] [--macros=<FILE:...>] [--nodigest] [--nosignature] [--rcfile=<FILE:...>] [-r|--root ROOT] [--querytags] [--showrc] [--quiet] [-v|--verbose] [--version] [-?|--help] [--usage] [--scripts] [--setperms] [--setugids] [--conflicts] [--obsoletes] [--provides] [--requires] [--info] [--changelog] [--xml] [--triggers] [--last] [--dupes] [--filesbypkg] [--fileclass] [--filecolor] [--fscontext] [--fileprovide] [--filerequire] [--filecaps]



Hm.


Ok.


I'll check the man page.


Excerpts from:
linux.die.net/man/8/rpm
Authors:
- Marc Ewing <marc@redhat.com>
- Jeff Johnson <jbj@redhat.com>
- Erik Troan <ewt@redhat.com>

Description

rpm is a powerful Package Manager, which can be used to build, install, query, verify, update, and erase individual software packages. A package consists of an archive of files and meta-data used to install and erase the archive files. The meta-data includes helper scripts, file attributes, and descriptive information about the package. Packages come in two varieties: binary packages, used to encapsulate software to be installed, and source packages, containing the source code and recipe necessary to produce binary packages.

[...]

Query Options

The general form of an rpm query command is

rpm {-q|--query} [select-options] [query-options]


[...]

Package Selection Options:

[Query installed package named PACKAGE_NAME.]
PACKAGE_NAME

[Query all installed packages.]
-a, --all

[...]

[Query an (uninstalled) package PACKAGE_FILE. The PACKAGE_FILE may be specified as an ftp or http style URL, in which case the package header will be downloaded and queried.]
-p, --package PACKAGE_FILE

[...]

Package Query Options:

[Display package information, including name, version, and description.]
-i, --info

[...]

Digital Signature and Digest Verification

The general forms of rpm digital signature commands are

rpm --import PUBKEY ...


rpm {--checksig} [--nosignature] [--nodigest] PACKAGE_FILE ...


The
--checksig
option checks all the digests and signatures contained in PACKAGE_FILE to ensure the integrity and origin of the package. Note that signatures are now verified whenever a package is read, and
--checksig
is useful to verify all of the digests and signatures associated with a package.

Digital signatures cannot be verified without a public key. An ASCII armored public key can be added to the rpm database using
--import
. An imported public key is carried in a header, and key ring management is performed exactly like package management. For example, all currently imported public keys can be displayed by:

rpm -qa gpg-pubkey*


Details about a specific public key, when imported, can be displayed by querying. Here's information about the Red Hat GPG/DSA key:

rpm -qi gpg-pubkey-db42a60e


Finally, public keys can be erased after importing just like packages. Here's how to remove the Red Hat GPG/DSA key

rpm -e gpg-pubkey-db42a60e



Key section: "key ring management is performed exactly like package management"
I think this means that when rpm imports keys, it puts them into package format and treats them as packages. So, to examine keys in rpm, use the rpm package database query tools.

Key section: "all currently imported public keys can be displayed by:
rpm -qa gpg-pubkey*
"

The -i flag is included in the --help and --usage output, and tells rpm to perform an installation. In the man page, however, it is also used together with the -q (query) flag to get information about a package.
The --help and --usage outputs mention the flag --info (list descriptive information from package(s)). The man page notes that -i == --info.
I think that when as long as the -q flag is present, -i will be interpreted by rpm as "info" not "install".


How can I list all installed packages?


Google "rpm list all packages".


Excerpt from:
www.redhat.com/archives/rhl-list/2005-November/msg00394.html
From: Ben Stringer <ben burbong com>
To: For users of Fedora Core releases <fedora-list redhat com>
Subject: Re: rpm "list package names only"
Date: Thu, 03 Nov 2005 11:19:59 +1100

On Thu, 2005-11-03 at 13:13 +1300, Morgan Read wrote:
> Hi,
>
> I want a list of installed packages by package name only (i.e. no version,
> release, .rpm, etc.)
>
> How do I do it?

It's documented in the manpage - use the "--qf" option to format the
results as you want them.

Eg.

rpm -qa --qf "%{NAME}\n"



Ok.

rpm -qa
makes sense, given that this command on the man page:
rpm -qa gpg-pubkey*

will display all currently imported public keys i.e. all packages whose names begin with "gpg-pubkey".


Switch back to Kalkin.



[root@kalkin work]# rpm -qa

setup-2.8.14-23.el6.noarch
basesystem-10.0-4.el6.noarch
kernel-firmware-2.6.32-696.el6.noarch
glibc-common-2.12-1.209.el6.x86_64
glibc-2.12-1.209.el6.x86_64
bash-4.1.2-48.el6.x86_64
libcap-2.16-5.5.el6.x86_64
info-4.13a-8.el6.x86_64
audit-libs-2.4.5-6.el6.x86_64
libacl-2.2.49-7.el6.x86_64
nspr-4.13.1-1.el6.x86_64
libselinux-2.0.94-7.el6.x86_64
sed-4.2.1-10.el6.x86_64
readline-6.0-4.el6.x86_64
gawk-3.1.7-10.el6_7.3.x86_64
libudev-147-2.73.el6_8.2.x86_64
file-libs-5.04-30.el6.x86_64
dbus-libs-1.2.24-8.el6_6.x86_64
pcre-7.8-7.el6.x86_64
lua-5.1.4-4.1.el6.x86_64
cyrus-sasl-lib-2.1.23-15.el6_6.2.x86_64
expat-2.0.1-13.el6_8.x86_64
elfutils-libelf-0.164-2.el6.x86_64
libgcrypt-1.4.5-12.el6_8.x86_64
findutils-4.4.2-9.el6.x86_64
checkpolicy-2.0.22-1.el6.x86_64
which-2.19-6.el6.x86_64
pth-2.0.7-9.3.el6.x86_64
sysvinit-tools-2.87-6.dsf.el6.x86_64
libtasn1-2.3-6.el6_5.x86_64
p11-kit-trust-0.18.5-2.el6_5.2.x86_64
gmp-4.3.1-12.el6.x86_64
libnih-1.0.1-7.el6.x86_64
file-5.04-30.el6.x86_64
psmisc-22.6-24.el6.x86_64
vim-minimal-7.4.629-5.el6_8.1.x86_64
procps-3.2.8-45.el6.x86_64
e2fsprogs-libs-1.41.12-23.el6.x86_64
binutils-2.20.51.0.2-5.46.el6.x86_64
diffutils-2.8.1-28.el6.x86_64
dash-0.5.5.1-4.el6.x86_64
groff-1.18.1.4-21.el6.x86_64
coreutils-libs-8.4-46.el6.x86_64
cracklib-2.8.16-4.el6.x86_64
coreutils-8.4-46.el6.x86_64
module-init-tools-3.9-26.el6.x86_64
redhat-logos-60.0.14-12.el6.centos.noarch
libpciaccess-0.13.4-1.el6.x86_64
nss-3.27.1-13.el6.x86_64
nss-tools-3.27.1-13.el6.x86_64
libedit-2.11-4.20080712cvs.1.el6.x86_64
mingetty-1.08-5.el6.x86_64
krb5-libs-1.10.3-65.el6.x86_64
libssh2-1.4.2-2.el6_7.1.x86_64
rpm-libs-4.8.0-55.el6.x86_64
rpm-4.8.0-55.el6.x86_64
gnupg2-2.0.14-8.el6.x86_64
fipscheck-lib-1.2.0-7.el6.x86_64
mysql-libs-5.1.73-8.el6_8.x86_64
pciutils-libs-3.1.10-4.el6.x86_64
libcap-ng-0.6.4-3.el6_0.1.x86_64
python-2.6.6-66.el6_8.x86_64
python-pycurl-7.19.0-9.el6.x86_64
pygpgme-0.1-18.20090824bzr68.el6.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
newt-0.52.11-4.el6.x86_64
ustr-1.0.4-9.1.el6.x86_64
shadow-utils-4.1.5.1-5.el6.x86_64
libutempter-1.1.5-4.1.el6.x86_64
gamin-0.1.10-9.el6.x86_64
shared-mime-info-0.70-6.el6.x86_64
grubby-7.0.15-7.el6.x86_64
yum-plugin-fastestmirror-1.1.30-40.el6.noarch
dbus-glib-0.86-6.el6.x86_64
centos-release-6-9.el6.12.3.x86_64
iptables-1.4.7-16.el6.x86_64
libdrm-2.4.65-2.el6.x86_64
plymouth-0.8.3-29.el6.centos.x86_64
initscripts-9.03.58-1.el6.centos.x86_64
device-mapper-libs-1.02.117-12.el6.x86_64
device-mapper-event-libs-1.02.117-12.el6.x86_64
device-mapper-event-1.02.117-12.el6.x86_64
cryptsetup-luks-libs-1.2.0-11.el6.x86_64
kpartx-0.4.9-100.el6.x86_64
cyrus-sasl-2.1.23-15.el6_6.2.x86_64
cronie-anacron-1.4.4-16.el6_8.2.x86_64
crontabs-1.10-33.el6.noarch
selinux-policy-3.7.19-307.el6.noarch
kbd-1.15-11.el6.x86_64
dracut-kernel-004-409.el6_8.2.noarch
fuse-2.8.3-5.el6.x86_64
system-config-firewall-base-1.2.27-7.2.el6_6.noarch
cryptsetup-luks-1.2.0-11.el6.x86_64
openssh-clients-5.3p1-122.el6.x86_64
mdadm-3.3.4-8.el6.x86_64
dhclient-4.1.1-53.P1.el6.centos.x86_64
passwd-0.77-7.el6.x86_64
grub-0.97-99.el6.x86_64
sudo-1.8.6p3-27.el6.x86_64
e2fsprogs-1.41.12-23.el6.x86_64
acl-2.2.49-7.el6.x86_64
bridge-utils-1.2-10.el6.x86_64
libgcc-4.4.7-18.el6.x86_64
filesystem-2.4.30-3.el6.x86_64
ncurses-base-5.7-4.20090207.el6.x86_64
tzdata-2016j-1.el6.noarch
nss-softokn-freebl-3.14.3-23.3.el6_8.x86_64
ncurses-libs-5.7-4.20090207.el6.x86_64
libattr-2.4.44-7.el6.x86_64
zlib-1.2.3-29.el6.x86_64
popt-1.13-7.el6.x86_64
libcom_err-1.41.12-23.el6.x86_64
db4-4.7.25-22.el6.x86_64
libsepol-2.0.41-4.el6.x86_64
chkconfig-1.3.49.5-1.el6.x86_64
nss-util-3.27.1-3.el6.x86_64
bzip2-libs-1.0.5-7.el6_0.x86_64
libuuid-2.17.2-12.28.el6.x86_64
libblkid-2.17.2-12.28.el6.x86_64
libgpg-error-1.7-4.el6.x86_64
libstdc++-4.4.7-18.el6.x86_64
grep-2.20-6.el6.x86_64
sqlite-3.6.20-1.el6_7.2.x86_64
libidn-1.18-2.el6.x86_64
xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64
nss-softokn-3.14.3-23.3.el6_8.x86_64
bzip2-1.0.5-7.el6_0.x86_64
libselinux-utils-2.0.94-7.el6.x86_64
cpio-2.10-13.el6.x86_64
libxml2-2.7.6-21.el6_8.1.x86_64
tcp_wrappers-libs-7.6-58.el6.x86_64
libaio-0.3.107-10.el6.x86_64
p11-kit-0.18.5-2.el6_5.2.x86_64
device-mapper-persistent-data-0.6.2-0.1.rc7.el6.x86_64
libusb-0.1.12-23.el6.x86_64
upstart-0.6.5-16.el6.x86_64
pinentry-0.7.6-8.el6.x86_64
net-tools-1.60-114.el6.x86_64
tar-1.23-15.el6_8.x86_64
db4-utils-4.7.25-22.el6.x86_64
libss-1.41.12-23.el6.x86_64
m4-1.4.13-5.el6.x86_64
make-3.81-23.el6.x86_64
ncurses-5.7-4.20090207.el6.x86_64
less-436-13.el6.x86_64
gzip-1.3.12-24.el6.x86_64
cracklib-dicts-2.8.16-4.el6.x86_64
pam-1.1.1-24.el6.x86_64
hwdata-0.233-18.1.el6.noarch
plymouth-scripts-0.8.3-29.el6.centos.x86_64
ca-certificates-2016.2.10-65.4.el6.noarch
nss-sysinit-3.27.1-13.el6.x86_64
logrotate-3.7.8-28.el6.x86_64
gdbm-1.8.0-39.el6.x86_64
keyutils-libs-1.4-5.el6.x86_64
openssl-1.0.1e-57.el6.x86_64
libcurl-7.19.7-52.el6.x86_64
curl-7.19.7-52.el6.x86_64
openldap-2.4.40-16.el6.x86_64
gpgme-1.1.8-3.el6.x86_64
fipscheck-1.2.0-7.el6.x86_64
ethtool-3.5-6.el6.x86_64
plymouth-core-libs-0.8.3-29.el6.centos.x86_64
libffi-3.0.5-3.2.el6.x86_64
python-libs-2.6.6-66.el6_8.x86_64
python-urlgrabber-3.9.1-11.el6.noarch
rpm-python-4.8.0-55.el6.x86_64
slang-2.2.1-1.el6.x86_64
newt-python-0.52.11-4.el6.x86_64
libsemanage-2.0.43-5.1.el6.x86_64
MAKEDEV-3.24-6.el6.x86_64
pkgconfig-0.23-9.1.el6.x86_64
glib2-2.28.8-9.el6.x86_64
libuser-0.56.13-8.el6_7.x86_64
yum-metadata-parser-1.1.2-16.el6.x86_64
yum-3.2.29-81.el6.centos.noarch
dhcp-common-4.1.1-53.P1.el6.centos.x86_64
policycoreutils-2.0.83-30.1.el6_8.x86_64
iproute-2.6.32-54.el6.x86_64
iputils-20071127-24.el6.x86_64
util-linux-ng-2.17.2-12.28.el6.x86_64
udev-147-2.73.el6_8.2.x86_64
device-mapper-1.02.117-12.el6.x86_64
openssh-5.3p1-122.el6.x86_64
lvm2-libs-2.02.143-12.el6.x86_64
device-mapper-multipath-libs-0.4.9-100.el6.x86_64
rsyslog-5.8.10-10.el6_6.x86_64
postfix-2.6.6-8.el6.x86_64
cronie-1.4.4-16.el6_8.2.x86_64
iptables-ipv6-1.4.7-16.el6.x86_64
kbd-misc-1.15-11.el6.noarch
dracut-004-409.el6_8.2.noarch
kernel-2.6.32-696.el6.x86_64
selinux-policy-targeted-3.7.19-307.el6.noarch
device-mapper-multipath-0.4.9-100.el6.x86_64
lvm2-2.02.143-12.el6.x86_64
openssh-server-5.3p1-122.el6.x86_64
b43-openfwwf-5.2-10.el6.noarch
iscsi-initiator-utils-6.2.0.873-26.el6.x86_64
authconfig-6.1.12-23.el6.x86_64
efibootmgr-0.5.4-15.el6.x86_64
audit-2.4.5-6.el6.x86_64
xfsprogs-3.1.1-20.el6.x86_64
attr-2.4.44-7.el6.x86_64
rootfiles-8.1-6.1.el6.noarch


[root@kalkin work]# rpm -qa | sort

acl-2.2.49-7.el6.x86_64
attr-2.4.44-7.el6.x86_64
audit-2.4.5-6.el6.x86_64
audit-libs-2.4.5-6.el6.x86_64
authconfig-6.1.12-23.el6.x86_64
b43-openfwwf-5.2-10.el6.noarch
basesystem-10.0-4.el6.noarch
bash-4.1.2-48.el6.x86_64
binutils-2.20.51.0.2-5.46.el6.x86_64
bridge-utils-1.2-10.el6.x86_64
bzip2-1.0.5-7.el6_0.x86_64
bzip2-libs-1.0.5-7.el6_0.x86_64
ca-certificates-2016.2.10-65.4.el6.noarch
centos-release-6-9.el6.12.3.x86_64
checkpolicy-2.0.22-1.el6.x86_64
chkconfig-1.3.49.5-1.el6.x86_64
coreutils-8.4-46.el6.x86_64
coreutils-libs-8.4-46.el6.x86_64
cpio-2.10-13.el6.x86_64
cracklib-2.8.16-4.el6.x86_64
cracklib-dicts-2.8.16-4.el6.x86_64
cronie-1.4.4-16.el6_8.2.x86_64
cronie-anacron-1.4.4-16.el6_8.2.x86_64
crontabs-1.10-33.el6.noarch
cryptsetup-luks-1.2.0-11.el6.x86_64
cryptsetup-luks-libs-1.2.0-11.el6.x86_64
curl-7.19.7-52.el6.x86_64
cyrus-sasl-2.1.23-15.el6_6.2.x86_64
cyrus-sasl-lib-2.1.23-15.el6_6.2.x86_64
dash-0.5.5.1-4.el6.x86_64
db4-4.7.25-22.el6.x86_64
db4-utils-4.7.25-22.el6.x86_64
dbus-glib-0.86-6.el6.x86_64
dbus-libs-1.2.24-8.el6_6.x86_64
device-mapper-1.02.117-12.el6.x86_64
device-mapper-event-1.02.117-12.el6.x86_64
device-mapper-event-libs-1.02.117-12.el6.x86_64
device-mapper-libs-1.02.117-12.el6.x86_64
device-mapper-multipath-0.4.9-100.el6.x86_64
device-mapper-multipath-libs-0.4.9-100.el6.x86_64
device-mapper-persistent-data-0.6.2-0.1.rc7.el6.x86_64
dhclient-4.1.1-53.P1.el6.centos.x86_64
dhcp-common-4.1.1-53.P1.el6.centos.x86_64
diffutils-2.8.1-28.el6.x86_64
dracut-004-409.el6_8.2.noarch
dracut-kernel-004-409.el6_8.2.noarch
e2fsprogs-1.41.12-23.el6.x86_64
e2fsprogs-libs-1.41.12-23.el6.x86_64
efibootmgr-0.5.4-15.el6.x86_64
elfutils-libelf-0.164-2.el6.x86_64
ethtool-3.5-6.el6.x86_64
expat-2.0.1-13.el6_8.x86_64
file-5.04-30.el6.x86_64
file-libs-5.04-30.el6.x86_64
filesystem-2.4.30-3.el6.x86_64
findutils-4.4.2-9.el6.x86_64
fipscheck-1.2.0-7.el6.x86_64
fipscheck-lib-1.2.0-7.el6.x86_64
fuse-2.8.3-5.el6.x86_64
gamin-0.1.10-9.el6.x86_64
gawk-3.1.7-10.el6_7.3.x86_64
gdbm-1.8.0-39.el6.x86_64
glib2-2.28.8-9.el6.x86_64
glibc-2.12-1.209.el6.x86_64
glibc-common-2.12-1.209.el6.x86_64
gmp-4.3.1-12.el6.x86_64
gnupg2-2.0.14-8.el6.x86_64
gpgme-1.1.8-3.el6.x86_64
grep-2.20-6.el6.x86_64
groff-1.18.1.4-21.el6.x86_64
grub-0.97-99.el6.x86_64
grubby-7.0.15-7.el6.x86_64
gzip-1.3.12-24.el6.x86_64
hwdata-0.233-18.1.el6.noarch
info-4.13a-8.el6.x86_64
initscripts-9.03.58-1.el6.centos.x86_64
iproute-2.6.32-54.el6.x86_64
iptables-1.4.7-16.el6.x86_64
iptables-ipv6-1.4.7-16.el6.x86_64
iputils-20071127-24.el6.x86_64
iscsi-initiator-utils-6.2.0.873-26.el6.x86_64
kbd-1.15-11.el6.x86_64
kbd-misc-1.15-11.el6.noarch
kernel-2.6.32-696.el6.x86_64
kernel-firmware-2.6.32-696.el6.noarch
keyutils-libs-1.4-5.el6.x86_64
kpartx-0.4.9-100.el6.x86_64
krb5-libs-1.10.3-65.el6.x86_64
less-436-13.el6.x86_64
libacl-2.2.49-7.el6.x86_64
libaio-0.3.107-10.el6.x86_64
libattr-2.4.44-7.el6.x86_64
libblkid-2.17.2-12.28.el6.x86_64
libcap-2.16-5.5.el6.x86_64
libcap-ng-0.6.4-3.el6_0.1.x86_64
libcom_err-1.41.12-23.el6.x86_64
libcurl-7.19.7-52.el6.x86_64
libdrm-2.4.65-2.el6.x86_64
libedit-2.11-4.20080712cvs.1.el6.x86_64
libffi-3.0.5-3.2.el6.x86_64
libgcc-4.4.7-18.el6.x86_64
libgcrypt-1.4.5-12.el6_8.x86_64
libgpg-error-1.7-4.el6.x86_64
libidn-1.18-2.el6.x86_64
libnih-1.0.1-7.el6.x86_64
libpciaccess-0.13.4-1.el6.x86_64
libselinux-2.0.94-7.el6.x86_64
libselinux-utils-2.0.94-7.el6.x86_64
libsemanage-2.0.43-5.1.el6.x86_64
libsepol-2.0.41-4.el6.x86_64
libss-1.41.12-23.el6.x86_64
libssh2-1.4.2-2.el6_7.1.x86_64
libstdc++-4.4.7-18.el6.x86_64
libtasn1-2.3-6.el6_5.x86_64
libudev-147-2.73.el6_8.2.x86_64
libusb-0.1.12-23.el6.x86_64
libuser-0.56.13-8.el6_7.x86_64
libutempter-1.1.5-4.1.el6.x86_64
libuuid-2.17.2-12.28.el6.x86_64
libxml2-2.7.6-21.el6_8.1.x86_64
logrotate-3.7.8-28.el6.x86_64
lua-5.1.4-4.1.el6.x86_64
lvm2-2.02.143-12.el6.x86_64
lvm2-libs-2.02.143-12.el6.x86_64
m4-1.4.13-5.el6.x86_64
make-3.81-23.el6.x86_64
MAKEDEV-3.24-6.el6.x86_64
mdadm-3.3.4-8.el6.x86_64
mingetty-1.08-5.el6.x86_64
module-init-tools-3.9-26.el6.x86_64
mysql-libs-5.1.73-8.el6_8.x86_64
ncurses-5.7-4.20090207.el6.x86_64
ncurses-base-5.7-4.20090207.el6.x86_64
ncurses-libs-5.7-4.20090207.el6.x86_64
net-tools-1.60-114.el6.x86_64
newt-0.52.11-4.el6.x86_64
newt-python-0.52.11-4.el6.x86_64
nspr-4.13.1-1.el6.x86_64
nss-3.27.1-13.el6.x86_64
nss-softokn-3.14.3-23.3.el6_8.x86_64
nss-softokn-freebl-3.14.3-23.3.el6_8.x86_64
nss-sysinit-3.27.1-13.el6.x86_64
nss-tools-3.27.1-13.el6.x86_64
nss-util-3.27.1-3.el6.x86_64
openldap-2.4.40-16.el6.x86_64
openssh-5.3p1-122.el6.x86_64
openssh-clients-5.3p1-122.el6.x86_64
openssh-server-5.3p1-122.el6.x86_64
openssl-1.0.1e-57.el6.x86_64
p11-kit-0.18.5-2.el6_5.2.x86_64
p11-kit-trust-0.18.5-2.el6_5.2.x86_64
pam-1.1.1-24.el6.x86_64
passwd-0.77-7.el6.x86_64
pciutils-libs-3.1.10-4.el6.x86_64
pcre-7.8-7.el6.x86_64
pinentry-0.7.6-8.el6.x86_64
pkgconfig-0.23-9.1.el6.x86_64
plymouth-0.8.3-29.el6.centos.x86_64
plymouth-core-libs-0.8.3-29.el6.centos.x86_64
plymouth-scripts-0.8.3-29.el6.centos.x86_64
policycoreutils-2.0.83-30.1.el6_8.x86_64
popt-1.13-7.el6.x86_64
postfix-2.6.6-8.el6.x86_64
procps-3.2.8-45.el6.x86_64
psmisc-22.6-24.el6.x86_64
pth-2.0.7-9.3.el6.x86_64
pygpgme-0.1-18.20090824bzr68.el6.x86_64
python-2.6.6-66.el6_8.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
python-libs-2.6.6-66.el6_8.x86_64
python-pycurl-7.19.0-9.el6.x86_64
python-urlgrabber-3.9.1-11.el6.noarch
readline-6.0-4.el6.x86_64
redhat-logos-60.0.14-12.el6.centos.noarch
rootfiles-8.1-6.1.el6.noarch
rpm-4.8.0-55.el6.x86_64
rpm-libs-4.8.0-55.el6.x86_64
rpm-python-4.8.0-55.el6.x86_64
rsyslog-5.8.10-10.el6_6.x86_64
sed-4.2.1-10.el6.x86_64
selinux-policy-3.7.19-307.el6.noarch
selinux-policy-targeted-3.7.19-307.el6.noarch
setup-2.8.14-23.el6.noarch
shadow-utils-4.1.5.1-5.el6.x86_64
shared-mime-info-0.70-6.el6.x86_64
slang-2.2.1-1.el6.x86_64
sqlite-3.6.20-1.el6_7.2.x86_64
sudo-1.8.6p3-27.el6.x86_64
system-config-firewall-base-1.2.27-7.2.el6_6.noarch
sysvinit-tools-2.87-6.dsf.el6.x86_64
tar-1.23-15.el6_8.x86_64
tcp_wrappers-libs-7.6-58.el6.x86_64
tzdata-2016j-1.el6.noarch
udev-147-2.73.el6_8.2.x86_64
upstart-0.6.5-16.el6.x86_64
ustr-1.0.4-9.1.el6.x86_64
util-linux-ng-2.17.2-12.28.el6.x86_64
vim-minimal-7.4.629-5.el6_8.1.x86_64
which-2.19-6.el6.x86_64
xfsprogs-3.1.1-20.el6.x86_64
xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64
yum-3.2.29-81.el6.centos.noarch
yum-metadata-parser-1.1.2-16.el6.x86_64
yum-plugin-fastestmirror-1.1.30-40.el6.noarch
zlib-1.2.3-29.el6.x86_64



Hm.

How many packages are there?

[root@kalkin work]# rpm -qa | wc -l

205


Total packages installed by default in Centos 6.9 Minimal: 205.

Note:
rpm -qa
does not include a new line at the end (which would increment by 1 the result of
wc -l
).

While installing Centos 6.9 Minimal on Kalkin, I noted that the installation GUI said that 205 packages were being installed.


Let's list all currently imported public keys.

[root@kalkin work]# rpm -qa gpg-pubkey*



Hm. Nothing.

[root@kalkin work]# rpm -qa gpg*

gpgme-1.1.8-3.el6.x86_64



Reading back over the sorted list of all installed rpm packages confirms that there are no packages whose names begin with "gpg-pubkey".


Hm.


In the .repo file, the key location was:
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6




[root@kalkin work]# ls etc/pki/rpm-gpg

RPM-GPG-KEY-CentOS-6
RPM-GPG-KEY-CentOS-Debug-6
RPM-GPG-KEY-CentOS-Security-6
RPM-GPG-KEY-CentOS-Testing-6

[root@kalkin work]# cat /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.5 (GNU/Linux) mQINBE4P06MBEACqn48FZgYkG2QrtUAVDV58H6LpDYEcTcv4CIFSkgs6dJ9TavCW NyPBZRpM2R+Rg5eVqlborp7TmktBP/sSsxc8eJ+3P2aQWSWc5ol74Y0OznJUCrBr bIdypJllsD9Fe+h7gLBXTh3vdBEWr2lR+xA+Oou8UlO2gFbVFQqMafUgU1s0vqaE /hHH0TzwD0/tJ6eqIbHwVR/Bu6kHFK4PwePovhfvyYD9Y+C0vOYd5Ict2vbLHz1f QBDZObv4M6KN3j7nzme47hKtdMd+LwFqxM5cXfM6b5doDulWPmuGV78VoX6OR7el x1tlfpuiFeuXYnImm5nTawArcQ1UkXUSYcTUKShJebRDLR3BycxR39Q9jtbOQ29R FumHginovEhdUcinRr22eRXgcmzpR00zFIWoFCwHh/OCtG14nFhefuZ8Z80qbVhW 2J9+/O4tksv9HtQBmQNOK5S8C4HNF2M8AfOWNTr8esFSDc0YA5/cxzdfOOtWam/w lBpNcUUSSgddRsBwijPuWhVA3NmA/uQlJtAo4Ji5vo8cj5MTPG3+U+rfNqRxu1Yc ioXRo4LzggPscaTZX6V24n0fzw0J2k7TT4sX007k+7YXwEMqmHpcMYbDNzdCzUer Zilh5hihJwvGfdi234W3GofttoO+jaAZjic7a3p6cO1ICMgfVqrbZCUQVQARAQAB tEZDZW50T1MtNiBLZXkgKENlbnRPUyA2IE9mZmljaWFsIFNpZ25pbmcgS2V5KSA8 Y2VudG9zLTYta2V5QGNlbnRvcy5vcmc+iQI8BBMBAgAmBQJOD9OjAhsDBQkSzAMA BgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQCUb8osEFud6ajRAAnb6d+w6Y/v/d MSy7UEy4rNquArix8xhqBwwjoGXpa37OqTvvcJrftZ1XgtzmTbkqXc+9EFch0C+w ST10f+H0SPTUGuPwqLkg27snUkDAv1B8laub+l2L9erzCaRriH8MnFyxt5v1rqWA mVlRymzgXK+EQDr+XOgMm1CvxVY3OwdjdoHNox4TdVQWlZl83xdLXBxkd5IRciNm sg5fJAzAMeg8YsoDee3m4khg9gEm+/Rj5io8Gfk0nhQpgGGeS1HEXl5jzTb44zQW qudkfcLEdUMOECbu7IC5Z1wrcj559qcp9C94IwQQO+LxLwg4kHffvZjCaOXDRiya h8KGsEDuiqwjU9HgGq9fa0Ceo3OyUazUi+WnOxBLVIQ8cUZJJ2Ia5PDnEsz59kCp JmBZaYPxUEteMtG3yDTa8c8jUnJtMPpkwpSkeMBeNr/rEH4YcBoxuFjppHzQpJ7G hZRbOfY8w97TgJbfDElwTX0/xX9ypsmBezgGoOvOkzP9iCy9YUBc9q/SNnflRWPO sMVrjec0vc6ffthu2xBdigBXhL7x2bphWzTXf2T067k+JOdoh5EGney6LhQzcp8m YCTENStCR+L/5XwrvNgRBnoXe4e0ZHet1CcCuBCBvSmsPHp5ml21ahsephnHx+rl JNGtzulnNP07RyfzQcpCNFH7W4lXzqM= =jrWY -----END PGP PUBLIC KEY BLOCK-----



It seems that the Centos 6 key file is already present on the system, and the repository settings are configured to find it.

Why then has it not already been imported into rpm?

When I set each active repository in CentOS-Base.repo to enabled=0, did this have any effect on the list of active keys stored within rpm?
- I doubt it. Changing config files should not affect the database, although, if it does, the database change could have been carried out when I next ran an
rpm
command.


From running this command earlier:

[root@kalkin work]# yum deplist rpms/gcc-4.4.7-18.el6.x86_64.rpm

Loaded plugins: fastestmirror
Finding dependencies:
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
Error: Could not open local rpm file: rpms/gcc-4.4.7-18.el6.x86_64.rpm: RPM Error opening Package


I know that the key ID of the key that signed the gcc package is c105b9de.


What is the key ID, exactly?


Google "key id gpg".


Second result:
superuser.com/questions/769452/what-is-a-openpgp-gnupg-key-id


Excerpts:

Q:

What is a OpenPGP/GnuPG key ID?

[...]

edited Jul 16 '15 at 15:08
Jens Erat

asked Jun 16 '14 at 14:22
Parthian Shot


A:

From RFC 4880 [ http://tools.ietf.org/html/rfc4880#section-12.2 ]:

A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field. The Key ID is the low-order 64 bits of the fingerprint.


For V3 keys, calculation is similar, but the key length is omitted.

In other words, the fingerprint is calculated from a constant, the packet length and finally a part of the public key packet. Further explanation on what's included (and thus how to calculate it) in the linked RFC.

The (long) key id is represented by the lowest 64 bits, and is used as the full fingerprint is an unhandy and long value. Even more often, the short key id formed by the lowest-order 32 bits is used. These short key IDs are often considered to have a too high chance of collisions [ http://www.debian-administration.org/users/dkg/weblog/105 ] and usage of at least the long ID, if not even full fingerprint is recommended.

Recapped in a few words:

The fingerprint is the hash value calculated from the public key packet. The key IDs are a part of the fingerprint:

Fingerprint: 0D69 E11F 12BD BA07 7B37 26AB 4E1F 799A A4FF 2279 Long key ID: 4E1F 799A A4FF 2279 Short key ID: A4FF 2279


Sometimes, the IDs get prefixed by
0x
as they're hex values.

edited Apr 3 '15 at 9:31
answered Jun 16 '14 at 15:41
Jens Erat




Excerpts from:
tools.ietf.org/html/rfc4880
Title: Request for Comments: 4880
Principle Authors:
- Jon Callas
- Lutz Donnerhacke
- Hal Finney
- David Shaw
- Rodney Thayer
Date: November 2007


This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.

[...]

Multiprecision integers (also called MPIs) are unsigned integers used to hold large integers such as the ones used in cryptographic calculations.

An MPI consists of two pieces: a two-octet scalar that is the length of the MPI in bits followed by a string of octets that contain the actual integer.

[...]

3.3. Key IDs

A Key ID is an eight-octet scalar that identifies a key. Implementations SHOULD NOT assume that Key IDs are unique.

[...]

5.5.2. Public-Key Packet Formats

There are two versions of key-material packets. Version 3 packets were first generated by PGP 2.6. Version 4 keys first appeared in PGP 5.0 and are the preferred key version for OpenPGP.

OpenPGP implementations MUST create keys with version 4 format. V3 keys are deprecated; an implementation MUST NOT generate a V3 key, but MAY accept it.

[...]

12.2. Key IDs and Fingerprints

For a V3 key, the eight-octet Key ID consists of the low 64 bits of the public modulus of the RSA key.

The fingerprint of a V3 key is formed by hashing the body (but not the two-octet length) of the MPIs that form the key material (public modulus n, followed by exponent e) with MD5. Note that both V3 keys and MD5 are deprecated.

A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field. The Key ID is the low-order 64 bits of the fingerprint.

[...]

Note that it is possible for there to be collisions of Key IDs -- two different keys with the same Key ID. Note that there is a much smaller, but still non-zero, probability that two different keys have the same fingerprint.

Also note that if V3 and V4 format keys share the same RSA key material, they will have different Key IDs as well as different fingerprints.




Excerpts from:
debian-administration.org/users/dkg/weblog/105
Author: dkg (Daniel Kahn Gillmor)
Date: Fri 13 Dec 2013

OpenPGPv4 fingerprints [ http://tools.ietf.org/html/rfc4880#section-12.2 ] are made from an SHA-1 digest over the key's public key material, creation date, and some boilerplate. SHA-1 digests are 160 bits in length. The "long key ID" of a key is the last 64 bits of the key's fingerprint. The "short key ID" of a key is the last 32 bits of the key's fingerprint. You can see both of the key IDs as a hash in and of themselves, as "32-bit truncated SHA-1" is a sort of hash (albeit not a cryptographically secure one).

I'm arguing here that short Key IDs and long Key IDs are actually useless, and we should stop using them entirely where we can do so.

[...]

Asheesh pointed out two years ago that OpenPGP short key IDs are bad because they are trivial to replicate. This is called a preimage attack against the short key ID (which is just a truncated fingerprint).

Today, David Leon Gil demonstrated that a collision attack against the long key ID is also trivial. A collision attack differs from a preimage attack in that the attacker gets to generate two different things that both have the same digest. Collision attacks are easier than preimage attacks because of the birthday paradox. dlg's colliding keys are not a surprise, but hopefully the explicit demonstration can serve as a wakeup call to help us improve our infrastructure.

The particularly bad news: gpg doesn't cope well with the two keys that have the same long key ID:

0 dkg@alice:~$ gpg --import x

gpg: key B8EBE1AF: public key "9E669861368BCA0BE42DAF7DDDA252EBB8EBE1AF" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1)


0 dkg@alice:~$ gpg --import y

gpg: key B8EBE1AF: doesn't match our copy
gpg: Total number processed: 1

2 dkg@alice:~$


This probably also means that
caff
(from the signing-party package) will also choke when trying to deal with these two keys.

I'm sure there are other OpenPGP-related tools that will fail in the face of two keys with matching 64-bit key IDs.

[...]

We want two things from a key management framework: unforgability, and human-intelligible handles. Key IDs fail at both.

- Fingerprints are unforgable (as much as SHA-1's preimage resistance, anyway -- that's a separate discussion), but they aren't human-intelligible.
- User IDs are human-intelligible, and they are unforgable if we can rely on a robust keysigning network.
- Key IDs (both short and long) are neither human-intelligible nor unforgable (regardless of existence of a keysigning network), so they are the worst of all possible worlds.

[...]

If we're not going to use Key IDs, what should we do instead?

For anything human-facing, we should be using human-intelligible things like user IDs and creation dates. These are trivial to forge, but people can relate to them. This is better than offering the user something that is also trivial to forge, but that people cannot relate to.

[...]

For anything not human-facing (e.g. key management data storage, etc), we should be using the full key itself. We'll also want to store the full fingerprint as an index, since that is used for communication and key exchange (e.g. on calling cards).

There remain parts of the spec (e.g. PK-ESK, Issuer subpackets) that make some use of the long key ID in ways that provide some measure of convenience but no real cryptographic security. We should fix the spec to stop using those, and either remove them entirely, or replace them with the full fingerprints. These fixes are not as urgent as the user-facing changes or the critical internal indexing fixes, though.




Summary:
- MPI == multi-precision-integer
- V3 == Version 3
- V4 == Version 4
- V3 keys are deprecated.
- The key ID of a V3 key is the last section of its public modulus.
- The fingerprint of a V3 key is the last section of a hash of several pieces of information, one of which is the key.
- The fingerprint of a V4 key is the last section of a hash of several pieces of information, one of which is the key.
- The key ID of a V4 key is the last section of its fingerprint.
- Implementation of RFC 4880 (e.g. GPG) should only create V4 keys. It may accept V3 keys.
- Key IDs are short "names" for keys, shorter than the fingerprint or the modulus. They are used for convenience, as less typing/reading is required and they are more human-intelligible. However, they are less secure, because another key with the same key ID can be generated (on purpose or by accident).
- A short key ID, e.g. A4FF 2279, is 8 hex characters. Each pair of hex characters represents one octet, so the short key ID consists of 4 octets (32 bits).
- A long key ID, e.g. 4E1F 799A A4FF 2279, is 16 hex characters. It therefore consists of 8 octets (64 bits).
- gpg has trouble handling two keys that have the same key ID.



From this line in the result of running
yum deplist rpms/gcc-4.4.7-18.el6.x86_64.rpm
:
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY


I see that the key that signed the gcc rpm package appears to be a V3 key.



Daniel Kahn Gillmor referred to a user ID, which was a distinct item from a key ID. What did he mean, exactly?


Google "gpg user id".


Excerpt from:
www.gnupg.org/gph/en/manual/c14.html

You must provide a user ID in addition to the key parameters. The user ID is used to associate the key being created with a real person.

You need a User-ID to identify your key; the software constructs the user id from Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>" Real name:


Only one user ID is created when a key is created, but it is possible to create additional user IDs if you want to use the key in two or more contexts, e.g., as an employee at work and a political activist on the side. A user ID should be created carefully since it cannot be edited after it is created.



Ah. So a user ID is some text that is a human-readable identifier for a key's user. It is of course easily forged (someone else can simply create a key or a message with the same user ID text). Digital signatures should be used to prove that a user ID is attached to a particular key/message (is this done by default within gpg?).


Hm. It would be better if the gcc rpm package would show me the fingerprint or the modulus of the key that signed it, rather than the key ID.


That said, I'll see if I can find the key ID of the Centos 6 key, and then I'll compare it to the key ID reported by the package.



Excerpt from the rpm man page:
linux.die.net/man/8/rpm

Using Gpg to Sign Packages

In order to sign packages using GPG, rpm must be configured to run GPG and be able to find a key ring with the appropriate keys. By default, rpm uses the same conventions as GPG to find key rings, namely the $GNUPGHOME environment variable. If your key rings are not located where GPG expects them to be, you will need to configure the macro %_gpg_path to be the location of the GPG key rings to use.

For compatibility with older versions of GPG, PGP, and rpm, only V3 OpenPGP signature packets should be configured. Either DSA or RSA verification algorithms can be used, but DSA is preferred.




Hm. So rpm uses gpg for dealing with key formats / checking signatures / etc. Older combinations of rpm and gpg expect V3 keys and signatures.

It would be worth checking if the Centos 6 key is V3 or V4.


aineko:Downloads stjohnpiano$ grep gpg available_tools_on_centos_69_minimal.txt

gpg
gpg-agent
gpg-connect-agent
gpg-error
gpg-zip
gpg2
gpgconf
gpgkey2ssh
gpgparsemail
gpgsplit
gpgv
gpgv2



gpg is available.


Switch to Kalkin.


[root@kalkin work]# gpg --version

gpg (GnuPG) 2.0.14
libgcrypt 1.4.5
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


[root@kalkin work]# gpg --help

gpg (GnuPG) 2.0.14
libgcrypt 1.4.5
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Syntax: gpg [options] [files]
sign, check, encrypt or decrypt
default operation depends on the input data

Commands: -s, --sign make a signature --clearsign make a clear text signature -b, --detach-sign make a detached signature -e, --encrypt encrypt data -c, --symmetric encryption only with symmetric cipher -d, --decrypt decrypt data (default) --verify verify a signature -k, --list-keys list keys --list-sigs list keys and signatures --check-sigs list and check key signatures --fingerprint list keys and fingerprints -K, --list-secret-keys list secret keys --gen-key generate a new key pair --delete-keys remove keys from the public keyring --delete-secret-keys remove keys from the secret keyring --sign-key sign a key --lsign-key sign a key locally --edit-key sign or edit a key --gen-revoke generate a revocation certificate --export export keys --send-keys export keys to a key server --recv-keys import keys from a key server --search-keys search for keys on a key server --refresh-keys update all keys from a keyserver --import import/merge keys --card-status print the card status --card-edit change data on a card --change-pin change a card's PIN --update-trustdb update the trust database --print-md print message digests --server run in server mode Options: -a, --armor create ascii armored output -r, --recipient USER-ID encrypt for USER-ID -u, --local-user USER-ID use USER-ID to sign or decrypt -z N set compress level to N (0 disables) --textmode use canonical text mode -o, --output FILE write output to FILE -v, --verbose verbose -n, --dry-run do not make any changes -i, --interactive prompt before overwriting --openpgp use strict OpenPGP behavior (See the man page for a complete listing of all commands and options) Examples: -se -r Bob [file] sign and encrypt for user Bob --clearsign [file] make a clear text signature --detach-sign [file] make a detached signature --list-keys [names] show keys --fingerprint [names] show fingerprints Please report bugs to <http://bugs.gnupg.org>.



Some reading suggested a candidate for getting the key ID:
gpg --with-fingerprint [path_to_key_file]



At this point, I made a mistake. I ran
gpg --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
without using
tee
to record the output (nor did I record it manually). I then ran
gpg --help
, which wiped this output off Kalkin's screen.

Running
gpg --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
again did not produce the same output (it's much shorter this time).

[root@kalkin work]# gpg --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

pub 4096R/C105B9DE 2011-07-03 CentOS-6 Key (CentOS 6 Official Signing Key) <centos-6-key@centos.org> Key fingerprint = C1DA C52D 1664 E8A4 386D BA43 0946 FCA2 C105 B9DE



Well, I have the Centos 6 key's keyID: C105B9DE
- The last 8 hex digits (i.e. 4 octets) of the key fingerprint are C105B9DE.
- The second item after the slash in "4096R/C105B9DE" is C105B9DE. 4096R probably means that the key is 4096-bit RSA.

In hex, case doesn't matter, so C105B9DE is the same as c105b9de (produced by
yum deplist
earlier). This suggests that the Centos 6 key was the key that signed the gcc rpm package (bearing in mind the caveats about the forgeability of key IDs).


Based on some knowledge of gpg and my memory of the non-recorded output, I think that running
gpg --with-fingerprint
for the first time caused gpg to create a keyring, which resulted in additional output.


[root@kalkin work]# ls -1a ~

.
..
anaconda-ks.cfg
.bash_history
.bash_logout
.bash_profile
.bashrc
.cshrc
.gnupg
install.log
install.log.syslog
.tcshrc

[root@kalkin work]# ls -1a ~/.gnupg

gpg.conf
pubring.gpg
secring.gpg
trustdb.gpg

[root@kalkin work]# gpg --list-keys



No keys are in gpg's key database ("keyring").


I'd like to get some more information about the key, if possible (e.g. is it V3/V4?).


Let's look at the gpg man page.


Excerpts from:
linux.die.net/man/1/gpg

gpg2 may be run with no commands, in which case it will perform a reasonable action depending on the type of file it is given as input (an encrypted message is decrypted, a signature is verified, a file containing keys is listed).

[...]

--dump-options

Print a list of all available options and commands.

[...]

--verify

Assume that the first argument is a signed file or a detached signature and verify it without generating any output. With no arguments, the signature packet is read from STDIN. If only a sigfile is given, it may be a complete signature or a detached signature, in which case the signed stuff is expected in a file without the ".sig" or ".asc" extension. With more than 1 argument, the first should be a detached signature and the remaining files are the signed stuff. To read the signed stuff from STDIN, use aq-aq as the second filename. For security reasons a detached signature cannot read the signed material from STDIN without denoting it in the above way.

[...]

--fingerprint

List all keys (or the specified ones) along with their fingerprints. This is the same output as --list-keys but with the additional output of a line with the fingerprint. May also be combined with --list-sigs or --check-sigs. If this command is given twice, the fingerprints of all secondary keys are listed too.

[...]

--keyid-format short|0xshort|long|0xlong
Select how to display key IDs. "short" is the traditional 8-character key ID. "long" is the more accurate (but less convenient) 16-character key ID. Add an "0x" to either to include an "0x" at the beginning of the key ID, as in 0x99242560.

[...]

--with-fingerprint

Same as the command --fingerprint but changes only the format of the output and may be used together with another command.

[...]

--no-default-keyring

Do not add the default keyrings to the list of keyrings. Note that GnuPG will not operate without any keyrings, so if you use this option and do not provide alternate keyrings via --keyring or --secret-keyring, then GnuPG will still use the default public or secret keyrings.



Key sections:
- "gpg2 may be run with no commands, in which case it will perform a reasonable action depending on the type of file it is given as input (an encrypted message is decrypted, a signature is verified, a file containing keys is listed)."
- "GnuPG will not operate without any keyrings"


I can't see much information in the man page about analysing a standalone key file that hasn't been imported. Perhaps the gpg developers were not particularly interested in this problem.



[root@kalkin work]# gpg /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

pub 4096R/C105B9DE 2011-07-03 CentOS-6 Key (CentOS 6 Official Signing Key) <centos-6-key@centos.org>


[root@kalkin work]# gpg --with-fingerprint --keyid-format long /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

pub 4096R/0946FCA2C105B9DE 2011-07-03 CentOS-6 Key (CentOS 6 Official Signing Key) <centos-6-key@centos.org> Key fingerprint = C1DA C52D 1664 E8A4 386D BA43 0946 FCA2 C105 B9DE






Google "gpg analyse key without importing".


First result:
stackoverflow.com/questions/22136029/how-to-display-gpg-key-details-without-importing-it


Excerpts:

Q:

How to display gpg key details without importing it?

I have a copy of the postgresql apt repository gpg key and would like to view the details of the gpg key as it comes in the file. Is this possible without importing it into a key ring?

edited Sep 18 '14 at 9:37
Jens Erat

asked Mar 3 '14 at 1:10
Amos Shapira


A:

There are several detail levels you can get when looking at OpenPGP key data: a basic summary, a machine-readable output of this summary or a detailed (and very technical) list of the individual OpenPGP packets.


Basic Key Information

For a brief peak at an OpenPGP key file, you can simply pass the filename as parameter or pipe in the key data through STDIN. If no command is passed, GnuPG tries to guess what you want to do -- and for key data, this is printing a summary on the key:

$ gpg a4ff2279.asc
gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa8192 2012-12-25 [SC] 0D69E11F12BDBA077B3726AB4E1F799AA4FF2279 uid Jens Erat (born 1988-01-19 in Stuttgart, Germany) uid Jens Erat <jens.erat@fsfe.org> uid Jens Erat <jens.erat@uni-konstanz.de> uid Jens Erat <jabber@jenserat.de> uid Jens Erat <email@jenserat.de> uid [jpeg image of size 12899] sub rsa4096 2012-12-26 [E] [revoked: 2014-03-26] sub rsa4096 2012-12-26 [S] [revoked: 2014-03-26] sub rsa2048 2013-01-23 [S] [expires: 2023-01-21] sub rsa2048 2013-01-23 [E] [expires: 2023-01-21] sub rsa4096 2014-03-26 [S] [expires: 2020-09-03] sub rsa4096 2014-03-26 [E] [expires: 2020-09-03] sub rsa4096 2014-11-22 [A] [revoked: 2016-03-01] sub rsa4096 2016-02-24 [A] [expires: 2020-02-23]


By setting
--keyid-format 0xlong
, long key IDs are printed instead of the insecure short key IDs:

$ gpg a4ff2279.asc
gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa8192/0x4E1F799AA4FF2279 2012-12-25 [SC] 0D69E11F12BDBA077B3726AB4E1F799AA4FF2279 uid Jens Erat (born 1988-01-19 in Stuttgart, Germany) uid Jens Erat <jens.erat@fsfe.org> uid Jens Erat <jens.erat@uni-konstanz.de> uid Jens Erat <jabber@jenserat.de> uid Jens Erat <email@jenserat.de> uid [jpeg image of size 12899] sub rsa4096/0x0F3ED8E6759A536E 2012-12-26 [E] [revoked: 2014-03-26] sub rsa4096/0x2D6761A7CC85941A 2012-12-26 [S] [revoked: 2014-03-26] sub rsa2048/0x9FF7E53ACB4BD3EE 2013-01-23 [S] [expires: 2023-01-21] sub rsa2048/0x5C88F5D83E2554DF 2013-01-23 [E] [expires: 2023-01-21] sub rsa4096/0x8E78E44DFB1B55E9 2014-03-26 [S] [expires: 2020-09-03] sub rsa4096/0xCC73B287A4388025 2014-03-26 [E] [expires: 2020-09-03] sub rsa4096/0x382D23D4C9773A5C 2014-11-22 [A] [revoked: 2016-03-01] sub rsa4096/0xFF37A70EDCBB4926 2016-02-24 [A] [expires: 2020-02-23] pub rsa1024/0x7F60B22EA4FF2279 2014-06-16 [SCEA] [revoked: 2016-08-16]


Providing
-v
or
-vv
will even add some more information. I prefer printing the package details in this case, though (see below).


Machine-Readable Output

GnuPG also has a colon-separated output format, which is easily parsable and has a stable format. The format is documented in GnuPG doc/DETAILS file. The option to receive this format is
--with-colons
.

$ gpg --with-colons a4ff2279.asc
gpg: WARNING: no command supplied. Trying to guess what you mean ...
pub:-:8192:1:4E1F799AA4FF2279:1356475387:::-:
uid:::::::::Jens Erat (born 1988-01-19 in Stuttgart, Germany):
uid:::::::::Jens Erat <jens.erat@fsfe.org>:
uid:::::::::Jens Erat <jens.erat@uni-konstanz.de>:
uid:::::::::Jens Erat <jabber@jenserat.de>:
uid:::::::::Jens Erat <email@jenserat.de>:
uat:::::::::1 12921:
sub:-:4096:1:0F3ED8E6759A536E:1356517233:1482747633:::
sub:-:4096:1:2D6761A7CC85941A:1356517456:1482747856:::
sub:-:2048:1:9FF7E53ACB4BD3EE:1358985314:1674345314:::
sub:-:2048:1:5C88F5D83E2554DF:1358985467:1674345467:::
sub:-:4096:1:8E78E44DFB1B55E9:1395870592:1599164118:::
sub:-:4096:1:CC73B287A4388025:1395870720:1599164118:::
sub:-:4096:1:382D23D4C9773A5C:1416680427:1479752427:::
sub:-:4096:1:FF37A70EDCBB4926:1456322829:1582466829:::


Since GnuPG 2.1.23, the
gpg: WARNING: no command supplied. Trying to guess what you mean ...
warning can be omitted by using the
--import-options show-only
option together with the
--import
command (this also works without
--with-colons
, of course):

$ gpg --with-colons --import-options show-only --import a4ff2279
[snip]


For older versions: the warning message is printed on STDERR, so you could just read STDIN to split apart the key information from the warning.


Technical Details: Listing OpenPGP Packets

Without installing any further packages, you can use
gpg --list-packets [file]
to view information on the OpenPGP packets contained in the file.

$ gpg --list-packets a4ff2279.asc :public key packet: version 4, algo 1, created 1356475387, expires 0 pkey[0]: [8192 bits] pkey[1]: [17 bits] keyid: 4E1F799AA4FF2279 :user ID packet: "Jens Erat (born 1988-01-19 in Stuttgart, Germany)" :signature packet: algo 1, keyid 4E1F799AA4FF2279 version 4, created 1356516623, md5len 0, sigclass 0x13 digest algo 2, begin of digest 18 46 hashed subpkt 27 len 1 (key flags: 03) [snip]


[...]

edited Sep 13 '17 at 16:20
answered Mar 3 '14 at 13:11
Jens Erat



I think the second example of using
$ gpg a4ff2279.asc
was meant to be
$ gpg --keyid-format 0xlong a4ff2279.asc
.

Also, in the first example, the short key ID was not shown in the output. In the second example, the long key ID was shown:
rsa8192/0x4E1F799AA4FF2279



Some investigation shows that the GnuPG doc/DETAILS file is located on Kalkin at /usr/share/doc/DETAILS.



[root@kalkin work]# gpg --with-colons /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

pub:-:4096:1:0946FCA2C105B9DE:1309660067:1625020067::-:CentOS-6 Key (CentOS 6 Official Signing Key) <centos-6-key@centos.org>:

[root@kalkin work]# gpg --list-packets /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

:public key packet: version 4, algo 1, created 1309660067, expires 0 pkey[0]: [4096 bits] pkey[1]: [17 bits] keyid: 0946FCA2C105B9DE :user ID packet: "CentOS-6 Key (CentOS 6 Official Signing Key) <centos-6-key@centos.org>" :signature packet: algo 1, keyid 0946FCA2C105B9DE version 4, created 1309660067, md5len 0, sigclass 0x13 digest algo 2, begin of digest 9a 8d hashed subpkt 2 len 4 (sig created 2011-07-03) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 9 len 4 (key expires after 10y0d0h0m) hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2) hashed subpkt 21 len 3 (pref-hash-algos: 2 8 3) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) subpkt 16 len 8 (issuer key ID 0946FCA2C105B9DE) data: [4096 bits]



I see that the key is version 4 (V4).

If the digital signature is V3, then it's presumably possible to tell gpg to produce a V3 signature using a V4 key.



Excerpts from the man page:
linux.die.net/man/1/gpg

--force-v3-sigs
--no-force-v3-sigs

OpenPGP states that an implementation should generate v4 signatures but PGP versions 5 through 7 only recognize v4 signatures on key material. This option forces v3 signatures for signatures on data. [...] --no-force-v3-sigs disables this option.



Yup. So the Centos 6 key is V4, but it was used to produce a V3 signature for the gcc package, probably for compatibility with older combinations of rpm and gpg, which expect V3 keys and signatures.




I'll move back to using rpm to analyse the gcc rpm package.


Selected rpm flags:

--query = query

[Query/Verify package selection options]
--package = query an uninstalled package file

[Package Query Options]
--info = information

[Query options (with --query)]
--configfiles = list all configuration files
--docfiles = list all documentation files
--dump = dump basic file information
--list = list files in package

[Options implemented via popt alias/exec]
--scripts = list install/erase scriptlets from package(s)
--conflicts = list capabilities this package conflicts with
--provides = list capabilities that this package provides
--requires = list capabilities required by package(s)
--filesbypkg = list all files from each package


After some reading and testing, I've made a list of commands to be run. Since they are all query commands (i.e. they use --query), I decided that, while making this list, I could run them to test that they worked without a high risk of unrecorded output describing permanent changes.


[root@kalkin work]# rpm --query rpms/gcc-4.4.7-18.el6.x86_64.rpm


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm


[root@kalkin work]# rpm --query --info rpms/gcc-4.4.7-18.el6.x86_64.rpm


[root@kalkin work]# rpm --query --info --package rpms/gcc-4.4.7-18.el6.x86_64.rpm


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --configfiles


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --docfiles


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --dump


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --list


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --filesbypkg


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --scripts


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --conflicts


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --provides


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --requires




Now I'll run these commands and record the output here.





[root@kalkin work]# rpm --query rpms/gcc-4.4.7-18.el6.x86_64.rpm

package rpms/gcc-4.4.7-18.el6.x86_64.rpm is not installed




[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
gcc-4.4.7-18.el6.x86_64




[root@kalkin work]# rpm --query --info rpms/gcc-4.4.7-18.el6.x86_64.rpm

package rpms/gcc-4.4.7-18.el6.x86_64.rpm is not installed




[root@kalkin work]# rpm --query --info --package rpms/gcc-4.4.7-18.el6.x86_64.rpm

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
Name : gcc Relocations: (not relocatable) Version : 4.4.7 Vendor: CentOS Release : 18.el6 Build Date: Tue 21 Mar 2017 04:27:30 PM GMT Install Date: (not installed) Build Host: c1bm.rdu2.centos.org Group : Development/Languages Source RPM: gcc-4.4.7-18.el6.src.rpm Size : 19497604 License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions Signature : RSA/SHA1, Thu 23 Mar 2017 03:01:10 PM GMT, Key ID 0946fca2c105b9de Packager : CentOS BuildSystem <http://bugs.centos.org> URL : http://gcc.gnu.org Summary : Various compilers (C, C++, Objective-C, Java, ...) Description : The gcc package contains the GNU Compiler Collection version 4.4. You'll need this package in order to compile C code.





[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --configfiles

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY




[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --docfiles

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
/usr/share/doc/gcc-4.4.7/COPYING
/usr/share/doc/gcc-4.4.7/COPYING.LIB
/usr/share/doc/gcc-4.4.7/COPYING3
/usr/share/doc/gcc-4.4.7/COPYING3.LIB
/usr/share/doc/gcc-4.4.7/ChangeLog-1997.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-1998.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-1999.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2000.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2001.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2002.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2003.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2004.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2005.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2006.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2007.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2008.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.dataflow.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.lib.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.ptr.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.tree-ssa.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.tuples.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.vta.bz2
/usr/share/doc/gcc-4.4.7/README.Portability
/usr/share/info/gcc.info.gz
/usr/share/info/gccinstall.info.gz
/usr/share/info/gccint.info.gz
/usr/share/man/man1/gcc.1.gz
/usr/share/man/man1/gcov.1.gz
/usr/share/man/man1/protoize.1.gz
/usr/share/man/man1/unprotoize.1.gz




[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --dump

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
/usr/bin/c89 224 1490112248 de48736f6e4153f03d0a5d38ceb6c6fdb7f054e8f47ddd6af0a3dbf14f27b931 0100755 root root 0 0 0 X
/usr/bin/c99 215 1490112248 2513c6d9984dd0a2058557bf00f06d8d5181734e41dcfe07be7ed86f2959622a 0100755 root root 0 0 0 X
/usr/bin/cc 3 1490112246 0000000000000000000000000000000000000000000000000000000000000000 0120777 root root 0 0 0 gcc
/usr/bin/gcc 264016 1490112281 2dc0fd8f053b0a131dcbe9307c445d2101425ec4e71e9a2f5ba2c861196abeab 0100755 root root 0 0 0 X
/usr/bin/gcov 39848 1490112281 359dc6425491f6209c3e011a2131fa288a4f15b1547ea0a58a37cc19ad3c3f44 0100755 root root 0 0 0 X
/usr/bin/protoize 68664 1490112281 84e59c22b841dcfc12f1ff9e99701de5faf9d6690160c1ea9fc50743868fe5cb 0100755 root root 0 0 0 X
/usr/bin/unprotoize 57504 1490112281 841ffb24f8a2cd6c503e3a13024735f84d72736b8c1b3c919aa9660f88b1aa0c 0100755 root root 0 0 0 X
/usr/bin/x86_64-redhat-linux-gcc 264016 1490112281 2dc0fd8f053b0a131dcbe9307c445d2101425ec4e71e9a2f5ba2c861196abeab 0100755 root root 0 0 0 X
/usr/lib/gcc 32 1490112212 0000000000000000000000000000000000000000000000000000000000000000 040755 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux 30 1490112248 0000000000000000000000000000000000000000000000000000000000000000 040755 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4 4096 1490112281 0000000000000000000000000000000000000000000000000000000000000000 040755 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32 4096 1490112280 0000000000000000000000000000000000000000000000000000000000000000 040755 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtbegin.o 1740 1490112220 d4dafcaf5816e92969829d4ed4b8d4046fea52a9cb46d407294f18e8a8e1bcd6 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtbeginS.o 2168 1490112220 81fbaf1efa6169ab4b86d20d9acb50e251720d4ea388a9b8bbd79c54cdbf72b3 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtbeginT.o 2048 1490112220 d0bfda0b86826c414d28746ed4a4f86648b83cdd206d2c94d45014ed4b10e0e2 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtend.o 1312 1490112220 a9f77a73b4d74771abcab42ed33090bdffd6f7299aaac1a20a2ea92a3427edae 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtendS.o 1568 1490112220 72dbfae0d7415f66ed4d47a801633bf56f888fb067a302b6cff90c5043c26b4a 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtfastmath.o 4088 1490112220 dea5178596b7afc12dbe078eca68b9330198edaefb5fdea4df5eaa2d83aee3bb 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtprec32.o 2100 1490112220 0a3c9d18aa1352290247c887721ddfe397f7a9a120c2c32331edf1e974248e16 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtprec64.o 2108 1490112220 73ee022dafd7fdae244fc053342532239bbd9b7e94ee7023809478d3fc1180b7 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtprec80.o 2100 1490112220 9f71ee8059d5b82c1a59611340c2455e711693ecc03a8c0b9b4c3207ae08da0b 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcc.a 3311740 1490112279 56057b081502ab6057d4a064accf860b8d4dc27130e6632c1025e8e579e24005 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcc_eh.a 45212 1490112279 7309c26885531f0b61000debc9925f0cf5b39d0586a6b77887ba65c158761817 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcc_s.so 18 1490112247 0000000000000000000000000000000000000000000000000000000000000000 0120777 root root 0 0 0 /lib/libgcc_s.so.1
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcov.a 34406 1490112279 84f2b5c8927d2957eeeaa4cb27ba5a9e005b1e8486a9462126ee14ca63a82201 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgomp.a 133776 1490112280 434e409a2f74fa0ba25b7a72216732e96a455831300736f163894c80ef2481bd 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgomp.so 28 1490112247 0000000000000000000000000000000000000000000000000000000000000000 0120777 root root 0 0 0 ../../../../libgomp.so.1.0.0
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libmudflap.a 45 1490112247 0000000000000000000000000000000000000000000000000000000000000000 0120777 root root 0 0 0 ../../../i686-redhat-linux/4.4.7/libmudflap.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libmudflap.so 39 1490112247 85a386f9ef5c5d70c70ed1ddbfafbcbb48152c6d8f48915226d719a790877899 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libmudflapth.a 47 1490112247 0000000000000000000000000000000000000000000000000000000000000000 0120777 root root 0 0 0 ../../../i686-redhat-linux/4.4.7/libmudflapth.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libmudflapth.so 41 1490112247 334da651d3ae7a2718377f3f385c2073ca339b4a1ace711c8d438e2a26a3ea98 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/SYSCALLS.c.X 88142 1490112215 51c4cf5d342f6da2e57857ee4676573261049c18b22c72ddde9c68f8bbbf45db 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtbegin.o 2608 1490112219 e4eef6e084104dbe06c8dfd4a66b880f17fb6c37e991dcdbf03ecc4418e06586 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtbeginS.o 2856 1490112219 799379e63633fb2c626cffadac7438b76f96c1f8e61fe886d25c1233a434d95c 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtbeginT.o 3112 1490112219 139fd483a50b36a6db9b56181d993eda59fcec56bc772f2f1031c7c5f5044831 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtend.o 1912 1490112219 65d6bffe3bdc23d05c132e6dbff2731459b5aedaa2f5b734dac8865101445148 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtendS.o 1912 1490112219 e95b6af4ade3e654d15de9ffc86a0f4ae78fec858435f19172ad2235d1a95ade 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtfastmath.o 3056 1490112219 43bf6a7b810ead902b283aa24deeabcde6f147364149cf488798e24e544fc3df 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtprec32.o 3008 1490112219 1890e0f84364d423ce0e58545e579d93fb7e6f64306428f087fb6c89bed05eae 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtprec64.o 3016 1490112219 689d1147ba9b6f1d129ff931e589d4ec657333600b4e8cbb8c7da20476ee566e 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtprec80.o 3008 1490112219 697ff9296c44426b943a742f8c7e1918d63804be1172b691ea3b5b8d4e9bee08 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include 4096 1490112248 0000000000000000000000000000000000000000000000000000000000000000 040755 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/abmintrin.h 1799 1490111871 4061082344a565617d6ff6306d02e42d0e375df29286bf2ef63f0ef0d076083f 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/ammintrin.h 3089 1490111871 714021ab938db89eebada19cf3615643145f32c1452bcbe3ae0761c17f5fdf5a 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/avxintrin.h 48009 1490111871 1f8624200f87e18077390827c214ed2b85103da2f02b6d229e7d911ee6f72e7c 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/bmiintrin.h 4346 1490111871 70298e1688ad3356fe5456bacc5507c79bbc371cb6699573843585114510ab72 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/bmmintrin.h 1161 1490111871 a2ab86d8f2395e0efa4060f42e2c639a15bc448c9efb485b7a9e5178b10b003c 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/cpuid.h 5589 1490111871 576f72f078f74239d40a6e4f3c537710d881e6f9e75c9f30106a52281e1e97db 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/cross-stdarg.h 2598 1490111871 5e02ea6aa411a51a295eaf41d1ebb29793f8d443d95c550110d8bb98baafa06a 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/emmintrin.h 49931 1490111871 957ee7b8ee162772cc3f1d87eec490ccf1380462bd943a04249d7fd17be8faaf 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/f16cintrin.h 3262 1490111871 b119ac86395c7c4b6fa6b8d069f002541225a0fd7beebae8db14f0caa672a0c9 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/float.h 7847 1490111871 22f58b86c8fa60f5e836cfab291b5888a410c3c1077659b70c1720ed72b548b9 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/fma4intrin.h 8978 1490111871 803b422179c958f94c7ef71cde0c3d54230ff06a1a72d7163b368f383df9a225 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/immintrin.h 3611 1490111871 71854b8db0c023d6fbabdd614755a369c36cf9fcc594b66dc3eed82724165e05 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/iso646.h 1279 1490111871 35d68e701a72c02d647173da8fb3fcec2b254aef52ba2d64f3ca9e98d0d34527 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/limits.h 3470 1490111871 5671faac95c83fafa1e3a8949e9f9d0962f063915b1b4885bb30be473082a41a 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/lwpintrin.h 3219 1490111871 acb14f3bc69a1e87b8fff006359f3489ae8961566b6af64b736cb42c26757c42 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/mm3dnow.h 6632 1490111871 a9d206dcac3c30c66ee780c0cfa2345b2cc0696c5173534daa082780e9c048d1 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/mm_malloc.h 1763 1490111871 577d6d8ff47206ee00b0d412bfbb6909a5c0cdbed521dacb941fec62e9e520ac 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/mmintrin.h 30625 1490111871 18c7370a333ca0b2e3a04eb3968b3993ab1d5fd6a4c7c3c2e5e4850c4fc75b43 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/nmmintrin.h 1379 1490111871 8f9e71e9e68fd8c5a9931b8fd1f7b670497e1e54cf8493eb6d62ac6d277b2fad 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/omp.h 3622 1490112237 76a0955b57850491ef24fbdf0f1e8a7081a92d3da9da6a06f9e9ee9d67461dda 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/pmmintrin.h 4272 1490111871 d6adb8f05cb0cdd5edb3dce885d0faed44062cb5b489648ec7e6b1f0fb021be2 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/popcntintrin.h 1599 1490111871 4eed77ee8db2d430e6b48077b7192df9a68edfe24c55bfafdf59c71460fb64fc 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/smmintrin.h 27677 1490111871 40a07b748de8f5d45c6fb916d1710f205e32863d8161a9aa3173fd0ae31a94ba 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stdarg.h 4203 1490111871 b2392aa3f1cad947c08daf6679f45e8a055cfa26907e4185ce9b1fca5134280e 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stdbool.h 1451 1490111871 a4bded14e4b04c32025e2985e21a50bc22e27e6509cd7ed8aab8fc0041cd5b48 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stddef.h 12542 1490111871 6daf7735d00d3de79db6331fa6dee71b225bcad9adddb29204e6182826011025 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stdfix.h 6001 1490111871 651e34ccf65ffe38c206162083570bce8d9a0cd6af98cd541de66a1f37b006fe 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/syslimits.h 330 1490111524 22dd0ab81baadd5a8d455b445855f341d419c7b0267beca235de00b7ec78e529 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/tbmintrin.h 5849 1490111871 ef36c4f0f41682060744bb9c1617f17afddc64cebb5f46c4fea624a8cc7ae47d 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/tmmintrin.h 8222 1490111871 66f294efeb1072d96a7104aa56e6c40a2ca9a2e9c1471fc94cc73456034545f2 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/unwind.h 10246 1490111871 bac928066dffb64e49a312836ae0df9e79e3512b61ed6a4a586967a1676795ad 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/varargs.h 139 1490111871 f9acb21973be5764aa2fd689c941ad963c1ecdd133f3a6529f279803135f8268 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/wmmintrin.h 4359 1490111871 9dbab5bf5c59ea48d1c48c14f092cf94f5887a8404a75193fb5dd2f28a4eaa13 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/x86intrin.h 1976 1490111871 650b5225d8918647560f7809c1edd38fc519d9b89d85bb203d5546df6f73e530 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/xmmintrin.h 41731 1490111871 fc9ae3e77ef8e6e232aaa72ef395abf899d174659d257add03f6100e4fe18fda 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/xopintrin.h 28360 1490111871 036e44ce722b30ad0d55771f39478356d138fe0068f5378a7d494a1d0f325a77 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc.a 3020142 1490112279 a5f0659c69180e8d2a240a5c30d8e6f72018154ede6c6a0f6463a2e2efe4580b 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_eh.a 57586 1490112279 1ecc9945f16c3b1dae4fd1383a15aafefc38973530879eb76f3cb0ebee779c51 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so 20 1490112247 0000000000000000000000000000000000000000000000000000000000000000 0120777 root root 0 0 0 /lib64/libgcc_s.so.1
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcov.a 42872 1490112279 d93f72f6d8390590858a55d090387506df138d95873e33eddb9491b26ec1d269 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgomp.a 170950 1490112281 ad64dcbb90aa232dce667b1866a88eb78001d38126e0622a408a7820b2215881 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgomp.so 34 1490112247 0000000000000000000000000000000000000000000000000000000000000000 0120777 root root 0 0 0 ../../../../lib64/libgomp.so.1.0.0
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgomp.spec 170 1490112237 0792393f176036b013504597968b2cee55c8655208ebb448a9b37ce4649884aa 0100644 root root 0 0 0 X
/usr/lib/gcc/x86_64-redhat-linux/4.4.7 5 1490112248 0000000000000000000000000000000000000000000000000000000000000000 0120777 root root 0 0 0 4.4.4
/usr/libexec/gcc 32 1490112212 0000000000000000000000000000000000000000000000000000000000000000 040755 root root 0 0 0 X
/usr/libexec/gcc/x86_64-redhat-linux 30 1490112248 0000000000000000000000000000000000000000000000000000000000000000 040755 root root 0 0 0 X
/usr/libexec/gcc/x86_64-redhat-linux/4.4.4 155 1490112281 0000000000000000000000000000000000000000000000000000000000000000 040755 root root 0 0 0 X
/usr/libexec/gcc/x86_64-redhat-linux/4.4.4/collect2 109792 1490112281 a1d730e6300969c0f6ead744321017493845557c6669987b00aae6f36825665e 0100755 root root 0 0 0 X
/usr/libexec/gcc/x86_64-redhat-linux/4.4.7 5 1490112248 0000000000000000000000000000000000000000000000000000000000000000 0120777 root root 0 0 0 4.4.4
/usr/libexec/getconf 20 1490112247 0000000000000000000000000000000000000000000000000000000000000000 040755 root root 0 0 0 X
/usr/libexec/getconf/default 19 1490112247 0000000000000000000000000000000000000000000000000000000000000000 0120777 root root 0 0 0 POSIX_V6_LP64_OFF64
/usr/share/doc/gcc-4.4.7 4096 1490113631 0000000000000000000000000000000000000000000000000000000000000000 040755 root root 0 0 0 X
/usr/share/doc/gcc-4.4.7/COPYING 18002 1231931189 231f7edcc7352d7734a96eef0b8030f77982678c516876fcb81e25b32d68564c 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/COPYING.LIB 26440 1231931189 32434afcc8666ba060e111d715bfdb6c2d5dd8a35fa4d3ab8ad67d8f850d2f2b 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/COPYING3 35147 1231931189 8ceb4b9ee5adedde47b31e975c1d90c73ad27b6b165a1dcd80c7c545eb65b903 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/COPYING3.LIB 7639 1231931189 a853c2ffec17057872340eee242ae4d96cbf2b520ae27d903e1b2fef1a5f9d1c 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog-1997.bz2 36959 1231931971 b5bccbf6d33ba76970bce681cb549b626c109a48a652975b7a31b48c8d14b038 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog-1998.bz2 138909 1231931971 7ff67a169bff3aa6d9085695cac9700ee8bdc7fff648d178bdfc024ba5da0dc6 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog-1999.bz2 166784 1231931971 7b824760ba968afed86497761b2f122f46d1130f1cbc60142af7b3d16c7d09d7 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog-2000.bz2 252955 1231931973 70a3cb58b4ab84f2c8b10d137610bfe1b34ead3889e3ca09f5291a8c1946bb12 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog-2001.bz2 251675 1231931973 9293b872c121b0b2bd06fc2b2ee9f62b0fb773354c274c685d34191900865b9f 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog-2002.bz2 265572 1231931973 573b49cc141e4e37cd05e0ed2649b343975204ea8d20da26221309cf2a49e781 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog-2003.bz2 287834 1231931973 2ec5b3fbc8a2690242f8465a5c5a6262523f0f75765131da1cd76d2d24f80018 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog-2004.bz2 374561 1231931973 5c848ba6b368f7550a19376e328f72e7417ac95d5678006b0663150aafbfb6a9 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog-2005.bz2 284457 1231931973 abafa95d91a0933b9f226448d21e6e5f702ef8889ce512ebd64253062c6fbbe2 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog-2006.bz2 183033 1232013947 0c4ca4c1178f5e2ea1461a3faeb88f22a92714da851db223fb94ea567f626165 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog-2007.bz2 279843 1231931973 88614134e87e75cb2ea551527ad438401602d887b8be7311351d9fa5f1ebfe51 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog-2008.bz2 230183 1237316643 e1db1dcd52cb386a81dae7110c238ff48f79f5964095892a9fe04240ac9522a8 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog.bz2 109920 1338450609 78e98beae2fe0b1854656b131e4ba1e19bc4fbbcbab963867a19251d368ddd57 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog.dataflow.bz2 37580 1231931971 c6ff328a364d6a7bbe1754b672da76151b3030e0c6d5b4f8fbe75e9c89bf20e9 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog.lib.bz2 33994 1231931973 3455e78cac505dd848d6c6e55dc8fcbbbd4201b6464fa26fc78720a147377df7 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog.ptr.bz2 4845 1231931973 45b97ccab45ffaa17ac00405379e4f2b67c28ccfdf604cc37f05d9f7b03d1cd5 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog.tree-ssa.bz2 132662 1231931971 8b7e5a5f649dacafd98240ead80e9c464aec1fe13ccbda2120b83f3cda0d98e6 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog.tuples.bz2 52716 1231931973 bc789b4aad92083030d01ebfaa8fc58732e1d10fb0676343510fc7e8ed6402fe 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/ChangeLog.vta.bz2 21637 1258640140 258a106237a4af564191a20d3b629c2f2bfdb21ed230c60b5d97dd4681d5cdaf 0100644 root root 0 1 0 X
/usr/share/doc/gcc-4.4.7/README.Portability 6066 1231931189 12b108842e85f375ca8482919b495b4140a3a5026dbf25aa32c542e0f4b2abdf 0100644 root root 0 1 0 X
/usr/share/info/gcc.info.gz 450426 1490112215 77da0bffe30d83be7e531fbfa795fcd08b3125eb7fe9cc809d4fc19a3138f990 0100644 root root 0 1 0 X
/usr/share/info/gccinstall.info.gz 60904 1490112215 5e172dd620c0e0cd3857957686d23f4844b94782518392e818b96f7dd76d4bd1 0100644 root root 0 1 0 X
/usr/share/info/gccint.info.gz 489527 1490112215 52931982c75c17544a97f46621a40fab6112db822f6f87b0f604fb50bbdaddc0 0100644 root root 0 1 0 X
/usr/share/locale/be/LC_MESSAGES/gcc.mo 10634 1490112215 f994b4f6633ad89aaaa139226eeb2a36e53845c3fdd2003982fe67c3070ca6fa 0100644 root root 0 0 0 X
/usr/share/locale/da/LC_MESSAGES/gcc.mo 155096 1490112215 4a1e165cab46b8cd9d106164edaa09741c4ee959c56402d8ead87eb09f3ccd9c 0100644 root root 0 0 0 X
/usr/share/locale/de/LC_MESSAGES/gcc.mo 774320 1490112215 f7a3baa9bb00be406a88e22a4b1c7e262ff997d348c77726152deaf6afbffc2b 0100644 root root 0 0 0 X
/usr/share/locale/el/LC_MESSAGES/gcc.mo 12274 1490112215 94869e02108cdb373e53822d48e7b39b184e39c555a177286de99416f41a3223 0100644 root root 0 0 0 X
/usr/share/locale/es/LC_MESSAGES/gcc.mo 894977 1490112215 2830a7c0ca55bb527b9c5586f1e9e15749ec32a91e2cdbf83c72a9907f60bb75 0100644 root root 0 0 0 X
/usr/share/locale/fi/LC_MESSAGES/gcc.mo 122015 1490112215 a7cdcd57eadb1d40a9fd8c1655e16240597e68d05ec871251e2d85d725b8ee71 0100644 root root 0 0 0 X
/usr/share/locale/fr/LC_MESSAGES/gcc.mo 214170 1490112215 a858289c1b9af5d721e7f72d0e0b501b293bb7a96e34183e1556b3781d0a1689 0100644 root root 0 0 0 X
/usr/share/locale/id/LC_MESSAGES/gcc.mo 873872 1490112215 ac0a53166a261746c20f17655fcb5e5c82a38605a20d7657bc799add3b295fa7 0100644 root root 0 0 0 X
/usr/share/locale/ja/LC_MESSAGES/gcc.mo 84528 1490112215 d76ef417782c13a003c7d2a5c0873e0b65fe389cf0e63a9848af8d7a2f98d7fa 0100644 root root 0 0 0 X
/usr/share/locale/nl/LC_MESSAGES/gcc.mo 87281 1490112215 a82a3b593fe69e946b30131d608adfaa8636651ef6c98e4b748a29fec3216a4a 0100644 root root 0 0 0 X
/usr/share/locale/ru/LC_MESSAGES/gcc.mo 618971 1490112215 bbebb3d2987b68a0b4cf9621b33b096acab9172a22ac5adcd17b35a6dae4a732 0100644 root root 0 0 0 X
/usr/share/locale/sr/LC_MESSAGES/gcc.mo 800175 1490112215 092967099907b250addfd1c508d0b9cc79f28e60499a6fcb247fca541e331aea 0100644 root root 0 0 0 X
/usr/share/locale/sv/LC_MESSAGES/gcc.mo 845967 1490112215 c49c22832198107bf3e2e31bb31309658acc799806de73523e2dc485361f0439 0100644 root root 0 0 0 X
/usr/share/locale/tr/LC_MESSAGES/gcc.mo 570652 1490112215 42ae68b1704fd935d8f8f9349cda3b0406c406b9486d3657631e4ef0468c053e 0100644 root root 0 0 0 X
/usr/share/locale/zh_CN/LC_MESSAGES/gcc.mo 671748 1490112215 c7ba9c0a1fd9afd2869d4ff024f335819f0ba7f6454f7c92cb17cc07a213113b 0100644 root root 0 0 0 X
/usr/share/locale/zh_TW/LC_MESSAGES/gcc.mo 474790 1490112215 783a5e13ae9fab5411e9350cc64db5524923f17d253837444208aa1d61c2de7e 0100644 root root 0 0 0 X
/usr/share/man/man1/gcc.1.gz 193343 1490112215 2f6d79acde794991e6268f271e41ed60631bd1a2296ce4505e7012d1e2d5027a 0100644 root root 0 1 0 X
/usr/share/man/man1/gcov.1.gz 8041 1490112215 187ace446d0f491d3f142a9cb3dd27e9b5a821fc9e036b4c00dcc8c5a2ced56c 0100644 root root 0 1 0 X
/usr/share/man/man1/protoize.1.gz 4215 1490112248 f0a884687eb324d23bd1d45c4abda8020e34d109ae7af6f19aee804a63675489 0100644 root root 0 1 0 X
/usr/share/man/man1/unprotoize.1.gz 40 1490112248 e2dc2180b7c32cda349b95ec02059bfc18d021cb604aa6ce5a144e3f25e2b77a 0100644 root root 0 1 0 X




[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --list

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
/usr/bin/c89
/usr/bin/c99
/usr/bin/cc
/usr/bin/gcc
/usr/bin/gcov
/usr/bin/protoize
/usr/bin/unprotoize
/usr/bin/x86_64-redhat-linux-gcc
/usr/lib/gcc
/usr/lib/gcc/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.4.4
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtbegin.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtbeginS.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtbeginT.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtendS.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtfastmath.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtprec32.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtprec64.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtprec80.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcc.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcc_eh.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcc_s.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcov.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgomp.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgomp.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libmudflap.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libmudflap.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libmudflapth.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libmudflapth.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/SYSCALLS.c.X
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtbegin.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtbeginS.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtbeginT.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtendS.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtfastmath.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtprec32.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtprec64.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtprec80.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/abmintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/ammintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/avxintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/bmiintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/bmmintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/cpuid.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/cross-stdarg.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/emmintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/f16cintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/float.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/fma4intrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/immintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/iso646.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/limits.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/lwpintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/mm3dnow.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/mm_malloc.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/mmintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/nmmintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/omp.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/pmmintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/popcntintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/smmintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stdarg.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stdbool.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stddef.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stdfix.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/syslimits.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/tbmintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/tmmintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/unwind.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/varargs.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/wmmintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/x86intrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/xmmintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/xopintrin.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_eh.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcov.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgomp.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgomp.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgomp.spec
/usr/lib/gcc/x86_64-redhat-linux/4.4.7
/usr/libexec/gcc
/usr/libexec/gcc/x86_64-redhat-linux
/usr/libexec/gcc/x86_64-redhat-linux/4.4.4
/usr/libexec/gcc/x86_64-redhat-linux/4.4.4/collect2
/usr/libexec/gcc/x86_64-redhat-linux/4.4.7
/usr/libexec/getconf
/usr/libexec/getconf/default
/usr/share/doc/gcc-4.4.7
/usr/share/doc/gcc-4.4.7/COPYING
/usr/share/doc/gcc-4.4.7/COPYING.LIB
/usr/share/doc/gcc-4.4.7/COPYING3
/usr/share/doc/gcc-4.4.7/COPYING3.LIB
/usr/share/doc/gcc-4.4.7/ChangeLog-1997.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-1998.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-1999.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2000.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2001.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2002.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2003.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2004.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2005.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2006.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2007.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog-2008.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.dataflow.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.lib.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.ptr.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.tree-ssa.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.tuples.bz2
/usr/share/doc/gcc-4.4.7/ChangeLog.vta.bz2
/usr/share/doc/gcc-4.4.7/README.Portability
/usr/share/info/gcc.info.gz
/usr/share/info/gccinstall.info.gz
/usr/share/info/gccint.info.gz
/usr/share/locale/be/LC_MESSAGES/gcc.mo
/usr/share/locale/da/LC_MESSAGES/gcc.mo
/usr/share/locale/de/LC_MESSAGES/gcc.mo
/usr/share/locale/el/LC_MESSAGES/gcc.mo
/usr/share/locale/es/LC_MESSAGES/gcc.mo
/usr/share/locale/fi/LC_MESSAGES/gcc.mo
/usr/share/locale/fr/LC_MESSAGES/gcc.mo
/usr/share/locale/id/LC_MESSAGES/gcc.mo
/usr/share/locale/ja/LC_MESSAGES/gcc.mo
/usr/share/locale/nl/LC_MESSAGES/gcc.mo
/usr/share/locale/ru/LC_MESSAGES/gcc.mo
/usr/share/locale/sr/LC_MESSAGES/gcc.mo
/usr/share/locale/sv/LC_MESSAGES/gcc.mo
/usr/share/locale/tr/LC_MESSAGES/gcc.mo
/usr/share/locale/zh_CN/LC_MESSAGES/gcc.mo
/usr/share/locale/zh_TW/LC_MESSAGES/gcc.mo
/usr/share/man/man1/gcc.1.gz
/usr/share/man/man1/gcov.1.gz
/usr/share/man/man1/protoize.1.gz
/usr/share/man/man1/unprotoize.1.gz




[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --filesbypkg

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY gcc /usr/bin/c89 gcc /usr/bin/c99 gcc /usr/bin/cc gcc /usr/bin/gcc gcc /usr/bin/gcov gcc /usr/bin/protoize gcc /usr/bin/unprotoize gcc /usr/bin/x86_64-redhat-linux-gcc gcc /usr/lib/gcc gcc /usr/lib/gcc/x86_64-redhat-linux gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4 gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32 gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtbegin.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtbeginS.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtbeginT.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtend.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtendS.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtfastmath.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtprec32.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtprec64.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/crtprec80.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcc.a gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcc_eh.a gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcc_s.so gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcov.a gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgomp.a gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgomp.so gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libmudflap.a gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libmudflap.so gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libmudflapth.a gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libmudflapth.so gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/SYSCALLS.c.X gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtbegin.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtbeginS.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtbeginT.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtend.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtendS.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtfastmath.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtprec32.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtprec64.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtprec80.o gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/abmintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/ammintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/avxintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/bmiintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/bmmintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/cpuid.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/cross-stdarg.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/emmintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/f16cintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/float.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/fma4intrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/immintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/iso646.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/limits.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/lwpintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/mm3dnow.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/mm_malloc.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/mmintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/nmmintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/omp.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/pmmintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/popcntintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/smmintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stdarg.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stdbool.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stddef.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stdfix.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/syslimits.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/tbmintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/tmmintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/unwind.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/varargs.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/wmmintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/x86intrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/xmmintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/xopintrin.h gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc.a gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_eh.a gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcov.a gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgomp.a gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgomp.so gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgomp.spec gcc /usr/lib/gcc/x86_64-redhat-linux/4.4.7 gcc /usr/libexec/gcc gcc /usr/libexec/gcc/x86_64-redhat-linux gcc /usr/libexec/gcc/x86_64-redhat-linux/4.4.4 gcc /usr/libexec/gcc/x86_64-redhat-linux/4.4.4/collect2 gcc /usr/libexec/gcc/x86_64-redhat-linux/4.4.7 gcc /usr/libexec/getconf gcc /usr/libexec/getconf/default gcc /usr/share/doc/gcc-4.4.7 gcc /usr/share/doc/gcc-4.4.7/COPYING gcc /usr/share/doc/gcc-4.4.7/COPYING.LIB gcc /usr/share/doc/gcc-4.4.7/COPYING3 gcc /usr/share/doc/gcc-4.4.7/COPYING3.LIB gcc /usr/share/doc/gcc-4.4.7/ChangeLog-1997.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog-1998.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog-1999.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog-2000.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog-2001.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog-2002.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog-2003.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog-2004.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog-2005.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog-2006.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog-2007.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog-2008.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog.dataflow.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog.lib.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog.ptr.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog.tree-ssa.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog.tuples.bz2 gcc /usr/share/doc/gcc-4.4.7/ChangeLog.vta.bz2 gcc /usr/share/doc/gcc-4.4.7/README.Portability gcc /usr/share/info/gcc.info.gz gcc /usr/share/info/gccinstall.info.gz gcc /usr/share/info/gccint.info.gz gcc /usr/share/locale/be/LC_MESSAGES/gcc.mo gcc /usr/share/locale/da/LC_MESSAGES/gcc.mo gcc /usr/share/locale/de/LC_MESSAGES/gcc.mo gcc /usr/share/locale/el/LC_MESSAGES/gcc.mo gcc /usr/share/locale/es/LC_MESSAGES/gcc.mo gcc /usr/share/locale/fi/LC_MESSAGES/gcc.mo gcc /usr/share/locale/fr/LC_MESSAGES/gcc.mo gcc /usr/share/locale/id/LC_MESSAGES/gcc.mo gcc /usr/share/locale/ja/LC_MESSAGES/gcc.mo gcc /usr/share/locale/nl/LC_MESSAGES/gcc.mo gcc /usr/share/locale/ru/LC_MESSAGES/gcc.mo gcc /usr/share/locale/sr/LC_MESSAGES/gcc.mo gcc /usr/share/locale/sv/LC_MESSAGES/gcc.mo gcc /usr/share/locale/tr/LC_MESSAGES/gcc.mo gcc /usr/share/locale/zh_CN/LC_MESSAGES/gcc.mo gcc /usr/share/locale/zh_TW/LC_MESSAGES/gcc.mo gcc /usr/share/man/man1/gcc.1.gz gcc /usr/share/man/man1/gcov.1.gz gcc /usr/share/man/man1/protoize.1.gz gcc /usr/share/man/man1/unprotoize.1.gz





[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --scripts

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY postinstall scriptlet (using /bin/sh): if [ -f /usr/share/info/gcc.info.gz ]; then /sbin/install-info \ --info-dir=/usr/share/info /usr/share/info/gcc.info.gz || : fi preuninstall scriptlet (using /bin/sh): if [ $1 = 0 -a -f /usr/share/info/gcc.info.gz ]; then /sbin/install-info --delete \ --info-dir=/usr/share/info /usr/share/info/gcc.info.gz || : fi





[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --conflicts

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
gdb < 5.1-2




[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --provides

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
gcc = 4.4.4-15.el6
gcc = 4.4.7-18.el6
gcc(x86-64) = 4.4.7-18.el6




[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --requires

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
/bin/sh
/bin/sh
/bin/sh
/sbin/install-info
/sbin/install-info
binutils >= 2.19.51.0.14-33
cloog-ppl >= 0.15
cpp = 4.4.7-18.el6
glibc-devel >= 2.2.90-12
libc.so.6()(64bit)
libc.so.6(GLIBC_2.11)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libgcc >= 4.4.7-18.el6
libgcc_s.so.1()(64bit)
libgomp = 4.4.7-18.el6
libgomp.so.1()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1






Note: This line:
warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY

was not recorded in the output of
tee -a work.log
.


I remember now that
2>&1
can be used in Bash to redirect errors/warnings (which are normally sent to stderr) to normal output (stdout), so that both will be piped to the next command.

I used e.g.
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --dump 2>&1 | less

to confirm that the warning appeared on the commands that produced more output than would fit on the screen.


The --package flag is required to target an uninstalled package file.


Looking at the result of running
rpm --query --info --package rpms/gcc-4.4.7-18.el6.x86_64.rpm
, I note:
- Source RPM: gcc-4.4.7-18.el6.src.rpm
- Signature : RSA/SHA1, Thu 23 Mar 2017 03:01:10 PM GMT, Key ID 0946fca2c105b9de
-- The key ID is 16 hex characters (so it's a "long" key ID). It matches the key ID produced by running
gpg --with-fingerprint --keyid-format long /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
(0946FCA2C105B9DE).


The --configfiles flag produced no output, so I presume that this gcc package, once installed, cannot be configured via editing config files. Essentially, it has one configuration.


The output of
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --dump

consists of lines such as:
/usr/bin/c89 224 1490112248 de48736f6e4153f03d0a5d38ceb6c6fdb7f054e8f47ddd6af0a3dbf14f27b931 0100755 root root 0 0 0 X

- This is the first line in the output.


What are the various fields of each --dump line?


Excerpts from:
linux.die.net/man/8/rpm

--dump
Dump file information as follows (implies -l):
path size mtime digest mode owner group isconfig isdoc rdev symlink

[...]

-l, --list
List files in package.



So in the output line above,
path = /usr/bin/c89
size = 224
mtime = 1490112248
digest = de48736f6e4153f03d0a5d38ceb6c6fdb7f054e8f47ddd6af0a3dbf14f27b931
mode = 0100755
owner = root
group = root
isconfig = 0
isdoc = 0
rdev = 0
symlink = X


Hm. I'd like to know more about these fields and what they mean.


Google "rpm --dump fields".


First result:
ftp.rpm.org/max-rpm/s1-rpm-query-parts.html


Excerpts:

Maximum RPM: Taking the RPM Package Manager to the Limit
Chapter 5. Getting Information About Packages

[...]

--dump: Display All Verifiable Information for Each File

The
--dump
option is used to display every piece of information RPM has on one or more files listed in its database. The information is listed in a very concise fashion. Since the
--dump
option displays file-related information, the list of files must be chosen by using the
-l
,
-c
, or
-d
options (or some combination thereof):

# rpm -ql --dump adduser
/usr/sbin/adduser 4442 841083888 ca5fa53dc74952aa5b5e3a5fa5d8904b 0100755
root root 0 0 0 X


What does all this stuff mean? Let's go through it, item-by-item:

The
/usr/sbin/adduser
is simple: it's the name of the file being
dump
'ed.

4442
is the size of the file, in bytes.

How about
841083888
? It's the time the file was last modified, in seconds past the Unix zero date of January 1, 1970.

The
ca5fa53dc74952aa5b5e3a5fa5d8904b
is the MD5 checksum of the file's contents, all 128 bits of it.

If you guessed
0100755
was the file's mode, you'd be right.

The first
root
represents the file's owner.

The second
root
is the file's group.

We'll take the next part
(0 0)
in one chunk. The first zero shows whether the file is a config file. If zero, as in this case, then the file is not a config file. The next zero shows whether the file is documentation. Again, since there is a zero here, this file isn't documentation, either.

The final
0
represents the file's major and minor numbers. These are set only for device special files. Otherwise, it will be zero.

If the file were a symlink, the spot taken by the
X
would contain a path pointing to the linked file.

Normally, the
--dump
option is used by people that want to extract the file-related information from RPM and process it somehow.



-l == --list
-c == --configfiles
-d == --docfiles


I haven't seen a 7-digit numeric permissions string before, only 3- or 4-digit (e.g. 644, 0755, 4755).


Each digit in a permissions string is octal and represents a sequence of 3 bits.
- 7 (octal) == 111 (binary)
- 6 (octal) == 110 (binary)
- 5 (octal) == 101 (binary)
- 4 (octal) == 100 (binary)
- 3 (octal) == 011 (binary)
- 2 (octal) == 010 (binary)
- 1 (octal) == 001 (binary)
- 0 (octal) == 000 (binary)

In a 3-digit octal permissions string, each digit represents the read/write/execute permissions for a file or directory (each corresponding to a single bit within the octal digit).
- 7 (octal) == 111 (binary) == read + write + execute
- 6 (octal) == 110 (binary) == read + write
- 5 (octal) == 101 (binary) == read + execute
- 4 (octal) == 100 (binary) == read
- 3 (octal) == 011 (binary) == write + execute
- 2 (octal) == 010 (binary) == write
- 1 (octal) == 001 (binary) == execute
- 0 (octal) == 000 (binary) == [no permissions]

The 3 octal digits represent permissions for 3 different types of user identity. They are in this order: owner, group, world.
- owner = user identity that owns the file
- group = any user identity that belongs to a group to which the owner also belongs.
- world = any user identity on the operating system.

The owner identity may not be the same as the user identity that created the file - ownership can be changed.

Example 3-digit octal permissions strings:
- 777 (octal) == 111 111 111 (binary) == owner, group, and world can all read + write + execute.
- 705 (octal) == 111 111 111 (binary) == owner can read + write + execute. group can do nothing. world can read + execute.
- 644 (octal) == 110 100 100 (binary) == owner can read + write. group and world can read.

In a 4-digit octal permissions string, the fourth (leftmost) digit represents 3 bits that encode 3 additional modes. In order, these 3 modes are "set user ID on execution", "set group ID on execution", and "restricted deletion". Their names can be abbreviated as "setuid", "setgid", and "sticky".
For this fourth digit:
- 7 (octal) == 111 (binary) == setuid + setgid + sticky
- 6 (octal) == 110 (binary) == setuid + setgid
- 5 (octal) == 101 (binary) == setuid + sticky
- 4 (octal) == 100 (binary) == setuid
- 3 (octal) == 011 (binary) == setgid + sticky
- 2 (octal) == 010 (binary) == setgid
- 1 (octal) == 001 (binary) == sticky
- 0 (octal) == 000 (binary) == [no additional modes]


[some reading and searching about 7-digit octal permission strings occurs here]


Excerpt from:
unix.stackexchange.com/questions/425713/file-mode-in-7-digit-octal-format

Q:

File mode in 7 digit octal format

rpm --dump
will print file mode in 7-digit octal format:

$ rpm -q --dump rpm | grep -E '/usr/bin/rpmdb|/var/lib/rpm ' | cut -d' ' -f1,5
/usr/bin/rpmdb 0100755
/var/lib/rpm 040755


What do all those digits mean? I guess some of it will be related to file type, but can I reproduce the same string given I have an existing file and standard command line tools (+ perl/python, etc. if necessary)?

I've looked at rpm(1), which does not reveal anything (only calls the field "mode"), and stat(1), which only mentions the usual 4-digit mode. Closest I got is this other question about 6-digit format on AIX [ http://unix.stackexchange.com/questions/350189/how-to-decode-6-digits-file-mode-on-aix ].

Edit: I just noticed it's sometimes 6 digits; question remains mostly the same, though.

asked Feb 21 at 17:31
Alois Mahdal


A:

This is the
st_mode
field of the
stat
structure: it encodes both the file type and the mode bits. Do
man 2 stat
(or perhaps
man 7 inode
) on a linux system and search for the section entitled "The file type and mode". E.g. 0100755 means "regular file with mode 755" and 040755 means "directory with mode 755".

BTW, the leading 0 means "octal" since these values are so specified in the header files. The number of digits is irrelevant: it's just what is needed to contain the full value.

edited Feb 21 at 18:03
answered Feb 21 at 17:41
Nick



Hm.

So:
- In the 7-digit mode
0100755
, the first digit (0) indicates that the digit string is octal, the next two digits (10) indicate that it's a file, and the last four digits have their normal meanings, as described above.



The rdev field "represents the file's major and minor numbers. These are set only for device special files. Otherwise, it will be zero."

Google "device special file meaning".

Excerpt from:
ibgwww.colorado.edu/~lessem/psyc5112/usail/concepts/filesystems/everything-is-a-file.html

Everything is a File

One of the unique things about Unix as an operating system is that regards everything as a file. Files can be divided into three categories; ordinary or plain files, directories, and special or device files.

Directories in Unix are properly known as directory files. They contain information such as owner, permissions, and size for a set of files.

Ordinary or plain files in Unix are not all text files. They may also contain ASCII text, binary data, and program input or output. Executable binaries (programs) are also files, as are commands. When a user enters a command, the associated file is retrieved and executed. This is an important feature and contributes to the flexibility of Unix.

Special files are also known as device files. In Unix all physical devices are accessed via device files; they are what programs use to communicate with hardware. Files hold information on location, type, and access mode for a specific device. There are two types of device files; character and block, as well as two modes of access.

Block device files are used to access block device I/O. Block devices do buffered I/O, meaning that the the data is collected in a buffer until a full block can be transfered.

Character device files are associated with character or raw device access. They are used for unbuffered data transfers to and from a device. Rather than transferring data in blocks the data is transfered character by character. One transfer can consist of multiple characters.

4. So what about a device that could be accessed in character or block mode? How many device files would it have?
- One.
- Two.
- There are no such devices.

Some devices, such as disk partitions, may be accessed in block or character mode. Because each device file corresponds to a single access mode, physical devices that have more than one access mode will have more than one device file.

Device files are found in the /dev directory. Each device is assigned a major and minor device number. The major device number identifies the type of device, i.e. all SCSI devices would have the same number as would all the keyboards. The minor device number identifies a specific device, i.e. the keyboard attached to this workstation.

Device files are created using the mknod command. The form for this command is:

mknod [device-name] [type] [major] [minor]

- device-name is the name of the device file
- type is either "c" for character or "b" for block
- major is the major device number
- minor is the minor device number

The major and minor device numbers are indexed to device switches. There are two types of device switches; cdevsw for character devices and bdevsw for block devices. These switches are kernel structures that hold the names of all the control routines for a device and tell the kernel which driver module to execute. Device switches are actually tables that look something like this:

- 0 keyboard
- 1 SCSIbus
- 2 tty
- 3 disk

Using the ls command in the /dev directory will show entries that look like:

brw-r----- 1 root sys 1, 0 Aug 31 16:01 /dev/sd1a


The "b" before the permissions indicates that this is a block device file. When a user enters /dev/sd1a the kernel sees the file opening, realizes that it's major device number 1, and calls up the SCSIbus function to handle it.



Note: I think
/dev/sd1a
should probably have been
/dev/sda1
.

Typos:
- In "One of the unique things about Unix as an operating system is that regards everything as a file.", add "it" before "regards".
- In "They may also contain ASCII text, binary data, and program input or output.", delete "also" (unless the writer meant "unicode file" instead of "text file" in the previous sentence).
- Various semicolons should be colons.


So: rdev will only be relevant for device files, which tell the kernel which driver to execute to communicate with a particular piece of hardware.
Future question: For block devices, is the buffer that stores the buffered I/O actually within the device file?


So in the output line above,
path = /usr/bin/c89 = path of the file under examination in this line.
size = 224 = size of the file in bytes.
mtime = 1490112248 = time the file was last modified, in seconds past the Unix zero date of January 1, 1970.
digest = de48736f6e4153f03d0a5d38ceb6c6fdb7f054e8f47ddd6af0a3dbf14f27b931 = 128-bit MD5 checksum of the file's contents.
mode = 0100755 = mode of the file (in this case, a regular file with permissions set to 0755)
owner = root = user identity that this file claims as its owner
group = root = group identity that this file claims as its group
isconfig = 0 = is this file a configuration file? 0 is "false". Therefore this file does not appear in the rpm output when the --configfiles flag is used.
isdoc = 0 = is this file a documentation file? 0 is "false". Therefore this file does not appear in the rpm output when the --docfiles flag is used.
rdev = 0 = is this file a device file? if not, then this value will be 0.
symlink = X = is this file a symlink to another file? if yes, then this value will be the path pointing to the linked file. if not, then this value will be X.


Note: Namespaces for users and groups are separate. There can be both a user called "root" and a group called "root". By convention, a user will belong to the group of the same name (and perhaps other groups), and so user "root" should normally be a member of the group "root". Note that user membership in groups depends on the system configuration, not on the file and its permissions.



I want to confirm that the various outputs of the rpm command with the different flags --dump, --list, --filesbypkg contain identical lists of files.


On Aineko:
- Manually copy-paste the outputs above into new text files. Don't copy the warning. Make sure that each file ends with a newline. Check a few lines in each file to confirm that there aren't any spaces at the end of any lines.
- Save these text files in Aineko's Downloads directory.


aineko:Downloads stjohnpiano$ ls

available_tools_on_centos_69_minimal.txt
dump.txt
filesbypkg.txt
list.txt

aineko:Downloads stjohnpiano$ head -1 dump.txt

/usr/bin/c89 224 1490112248 de48736f6e4153f03d0a5d38ceb6c6fdb7f054e8f47ddd6af0a3dbf14f27b931 0100755 root root 0 0 0 X

aineko:Downloads stjohnpiano$ head -1 dump.txt | sed 's/ .*//'

/usr/bin/c89

aineko:Downloads stjohnpiano$ cat dump.txt | sed 's/ .*//' > dump2.txt


aineko:Downloads stjohnpiano$ head -5 dump.txt

/usr/bin/c89 224 1490112248 de48736f6e4153f03d0a5d38ceb6c6fdb7f054e8f47ddd6af0a3dbf14f27b931 0100755 root root 0 0 0 X
/usr/bin/c99 215 1490112248 2513c6d9984dd0a2058557bf00f06d8d5181734e41dcfe07be7ed86f2959622a 0100755 root root 0 0 0 X
/usr/bin/cc 3 1490112246 0000000000000000000000000000000000000000000000000000000000000000 0120777 root root 0 0 0 gcc
/usr/bin/gcc 264016 1490112281 2dc0fd8f053b0a131dcbe9307c445d2101425ec4e71e9a2f5ba2c861196abeab 0100755 root root 0 0 0 X
/usr/bin/gcov 39848 1490112281 359dc6425491f6209c3e011a2131fa288a4f15b1547ea0a58a37cc19ad3c3f44 0100755 root root 0 0 0 X

aineko:Downloads stjohnpiano$ head -5 dump2.txt

/usr/bin/c89
/usr/bin/c99
/usr/bin/cc
/usr/bin/gcc
/usr/bin/gcov

aineko:Downloads stjohnpiano$ head -1 list.txt

/usr/bin/c89

aineko:Downloads stjohnpiano$ head -5 list.txt

/usr/bin/c89
/usr/bin/c99
/usr/bin/cc
/usr/bin/gcc
/usr/bin/gcov

aineko:Downloads stjohnpiano$ diff list.txt dump2.txt


aineko:Downloads stjohnpiano$ head -1 filesbypkg.txt

gcc /usr/bin/c89


aineko:Downloads stjohnpiano$ head -1 filesbypkg.txt | awk '{print $2}'

/usr/bin/c89

aineko:Downloads stjohnpiano$ cat filesbypkg.txt | awk '{print $2}' > filesbypkg2.txt


aineko:Downloads stjohnpiano$ head -1 filesbypkg2.txt

/usr/bin/c89

aineko:Downloads stjohnpiano$ head -5 filesbypkg.txt

gcc /usr/bin/c89 gcc /usr/bin/c99 gcc /usr/bin/cc gcc /usr/bin/gcc gcc /usr/bin/gcov


aineko:Downloads stjohnpiano$ head -5 filesbypkg2.txt

/usr/bin/c89
/usr/bin/c99
/usr/bin/cc
/usr/bin/gcc
/usr/bin/gcov

aineko:Downloads stjohnpiano$ diff list.txt filesbypkg2.txt



Confirmed: The various outputs of the rpm command with the different flags --dump, --list, --filesbypkg contain identical lists of files.

--list just produces a list of files. Good baseline output.

--filesbypkg outputs the package name before the file name. Probably useful when querying the entire database for a file name without knowing which package it belongs to.



I'll copy the output of
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --scripts

here for ease of reference:


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --scripts

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY postinstall scriptlet (using /bin/sh): if [ -f /usr/share/info/gcc.info.gz ]; then /sbin/install-info \ --info-dir=/usr/share/info /usr/share/info/gcc.info.gz || : fi preuninstall scriptlet (using /bin/sh): if [ $1 = 0 -a -f /usr/share/info/gcc.info.gz ]; then /sbin/install-info --delete \ --info-dir=/usr/share/info /usr/share/info/gcc.info.gz || : fi



I see that
/sbin/install-info
is called postinstall and preuninstall. It installs and uninstalls the file
/usr/share/info/gcc.info.gz
.

/sbin/install-info
appears in the output of
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --requires

(twice! why?), so it's a utility that gcc expects to find on the system.


I'd like to know which package provides the install-info utility.

[some experimentation and reading occurs here]

rpm flags:
--file = query/verify package(s) owning file
--all = query/verify all packages
-qa == --query --all

[root@kalkin work]# which install-info

/sbin/install-info

[root@kalkin work]# rpm --query --file /sbin/install-info

info-4.13a-8.el6.x86_64

[root@kalkin work]# rpm -qa | grep info

info-4.13a-8.el6.x86_64
shared-mime-info-0.70-6.el6.x86_64



The install-info tool is provided by the package info-4.13a-8.el6.x86_64.




I'll copy the output of
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --conflicts

here for ease of reference:


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --conflicts

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
gdb < 5.1-2



Hm.

"gdb" appears in the output of
rpm -qa
once:
gdbm-1.8.0-39.el6.x86_64

gdbm 1.8.0-39 has a lower version number than gdb 5.1.2.

Strange: The format of the string "gdb < 5.1-2" suggests a required dependency version i.e. "there's a conflict here because the version of gdb is less than 5.1-2". I thought that a "conflict" indicated that a package included a file to be installed at a file path that had already been used by another package. I therefore expected to see something like "file path x already used by package y", not "version of package y is not high enough".


Let's confirm this.


Excerpt from:
docstore.mik.ua/orelly/other/LRH/chp-8-sect-5.html
Title: Learning Red Hat Linux, 3rd Edition
Author: Bill McCarty
Published: March 2003
Publisher: O'Reilly

8.5.2 Conflicting File

Conflict is RPM's term for a situation in which two packages include one or more identically named files that have different contents. For example, suppose that package A contains a file named /etc/superconfig having 12 lines and that package B contains a file named /etc/superconfig having 13 lines. The two packages conflict, because the two instances of /etc/superconfig are inconsistent.

In the event of a conflict, only one of the two conflicting packages is likely to work properly. If you instruct RPM to install a package and RPM finds that one or more of the package files conflict with existing files, RPM reports the conflict and terminates without installing the package:

# rpm -ivh bad-1.0-1.i386.rpm

bad /bin/badfile conflicts with file from good-1.0-1


In its report, RPM gives the name of the file and the name of the package that originally installed the file. You can force RPM to install the package, by using the
-- replacefiles
option:

rpm -ivh --replacefiles [package]


In response, RPM saves and then replaces any conflicting configuration files; it overwrites other types of files. However, using the
-- replacefiles
option is a bit like hitting a malfunctioning mechanical device with a hammer. Sometimes, it's what you must do; but, more often, it merely causes damage. The better way to resolve a conflict is to decide which of the two conflicting packages you prefer. Then, delete the unwanted package and install the preferred one.


8.5.3 Failed Dependency

Packages are not always self-contained: some packages require that other packages be installed before they operate correctly. RPM can identify such dependencies. If you attempt to install a package before you install other packages it requires, RPM reports a "failed dependency" and terminates without installing the package:

# rpm -ivh bad-1.0-1.i386.rpm

failed dependencies: mefirst is needed by bad-1.0-1


To resolve a failed dependency, you should install the missing package (or packages) and then install the desired package. If you prefer, you can force RPM to install the package; however, the package may not operate correctly. To force package installation, specify the
-- nodeps
option:

rpm -ivh --nodeps bad-1.0-1.i386.rpm


However, a forcibly installed package is unlikely to work correctly.




How does rpm know that two files are different?


Excerpt from:
ftp.rpm.org/max-rpm/s1-rpm-install-additional-options.html

One thing that sets RPM apart from many other package managers is that it keeps track of all the files it installs in a database. Each file's database entry contains a variety of information about the file, including a means of summarizing the file's contents. By using these summaries, known as MD5 checksums, RPM can determine if a particular file is going to be replaced by a file with the same name, but different contents.


With a little thought, I could have deduced this from the fact that the MD5 digest was included in the output of
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --dump
.




What is gdb?


Google "gdb".


First result:
www.gnu.org/software/gdb


GDB: The GNU Project Debugger


What is GDB?

GDB, the GNU Project debugger, allows you to see what is going on `inside' another program while it executes -- or what another program was doing at the moment it crashed.

GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:

- Start your program, specifying anything that might affect its behavior.
- Make your program stop on specified conditions.
- Examine what has happened, when your program has stopped.
- Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another.

Those programs might be executing on the same machine as GDB (native), on another machine (remote), or on a simulator. GDB can run on most popular UNIX and Microsoft Windows variants, as well as on Mac OS X.


What Languages does GDB Support?

GDB supports the following languages (in alphabetical order):
- Ada
- Assembly
- C
- C++
- D
- Fortran
- Go
- Objective-C
- OpenCL
- Modula-2
- Pascal
- Rust



Google "is gdb required for gcc".

Excerpt from:
stackoverflow.com/questions/29801755/c-do-i-need-gcc-and-gdb-with-the-same-version-to-debug

Q:

C++: Do I need GCC and GDB with the same version to debug

I am developing in C++ on Windows with minGW. I have debugging problems at the moment.

I must use and old version of GCC (4.4). So I was just wondering if it is possible to compile with this old GCC and debug with a new GDB?

What is the link between the two of them?

[...]

asked Apr 22 '15 at 15:08
Plouff


A:

GDB and GCC are separate programs -- separate source bases (with a bit of shared code, though not much), generally separate maintainers, different release schedules, and different version numbers. They do share a bit of culture and of course there is some coordination.

GDB is reasonably good about backward compatibility. It even keeps workarounds for bugs in debuginfo emitted by older versions of GCC and sometimes other compilers. What this means is that you can usually upgrade GDB while keeping the same GCC version.

The reverse, though, is not always the case. Sometimes a new version of GCC emits debug info that an older GDB cannot understand. In this situation you must upgrade GDB as well. In some limited situations you can pass a compatibility flag to GCC to ask for downgraded debug info, but this isn't always possible. And, since it is simple to upgrade GDB, you might as well.

answered Apr 23 '15 at 2:02
Tom Tromey



Hm. It doesn't seem as though gcc requires gdb, although they can be used together.

gdb is not included in the output of
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --requires

or in the output of
[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --provides


Perhaps "gdb < 5.1-2" was a warning, like "warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY", that was sent to stderr.
In this case, it would be a warning to the user that, if the user wanted to use gdb to debug the output of gcc (i.e. compiled programs), then gdb version 5.1-2 or higher would be needed for use with this version of gcc (4.4.7-18).


Let's test by routing stderr to /dev/null.


[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --conflicts 2>/dev/null

gdb < 5.1-2

[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --conflicts 1>/dev/null

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY


Nope.
gdb < 5.1-2
was output, not an error message sent to stdout.



Is gdbm the same item as gdb?


Google "gdbm".

First result:
www.gnu.org.ua/software/gdbm

Excerpts:

GNU dbm (or GDBM, for short) is a library of database functions that use extensible hashing and work similar to the standard UNIX dbm. These routines are provided to a programmer needing to create and manipulate a hashed database.

The basic use of GDBM is to store key/data pairs in a data file. Each key must be unique and each key is paired with only one data item.

The library provides primitives for storing key/data pairs, searching and retrieving the data by its key and deleting a key along with its data. It also support sequential iteration over all key/data pairs in a database.

[...]

GNU gdbm is written by Philip A. Nelson, Jason Downs and Sergey Poznyakoff.



Hm.

gdbm != gdb.


So gdb is not currently installed on Kalkin.


Although... perhaps gdb has an odd package name (or odd command name) that is not "gdb".


Excerpt from:
web.eecs.umich.edu/~sugih/pointers/summary.html

To start gdb, just type
gdb
at the unix prompt. Gdb will give you a prompt that looks like this:
(gdb)
. From that prompt you can run your program, look at variables, etc., using the commands listed below (and others not listed). Or, you can start gdb and give it the name of the program executable you want to debug by saying

gdb [executable]


Well, gdb's command name is gdb, then.

If this is so, then gdb will be a binary file on the system.

It might be provided by a package with a name other than "gdb", but in that case I can use rpm to look up the package that contains a particular file.


[root@kalkin work]# which gdb

/usr/bin/which: no gdb in (/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)

[root@kalkin work]# rpm --query --all --filesbypkg | grep gdb

gdbm /usr/lib64/libgdbm.so.2 gdbm /usr/lib64/libgdbm.so.2.0.0 gdbm /usr/share/doc/gdbm-1.8.0 gdbm /usr/share/doc/gdbm-1.8.0/COPYING gdbm /usr/share/doc/gdbm-1.8.0/NEWS gdbm /usr/share/doc/gdbm-1.8.0/README python-libs /usr/lib64/python2.6/lib-dynload/gdbmmodule.so glib2 /etc/bash_completion.d/gdbus-bash-completion.sh glib2 /usr/bin/gdbus glib2 /usr/share/man/man1/gdbus.1.gz



Nope. gdb is not installed on Kalkin.


How many files are registered in the rpm database?

[root@kalkin work]# rpm --query --all --filesbypkg | wc -l

31491


31491 files.


The word "conflicts" appears once in the man page for rpm.

Excerpt from:
linux.die.net/man/8/rpm

--test = Do not install the package, simply check for and report potential conflicts.


I didn't spot this option before.

Perhaps other versions of the man page include an explanation of the --conflicts option.


Incidentally,
man page == manual page


I don't have the
man
utility installed on Kalkin.

aineko:Downloads stjohnpiano$ grep man available_tools_on_centos_69_minimal.txt

command


[root@kalkin work]# rpm --query --all | grep man

libsemanage-2.0.43-5.1.el6.x86_64

[root@kalkin work]# man --version

-bash: man: command not found

[root@kalkin work]# which man

/usr/bin/which: no man in (/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)



Hm. Well, man page files turned up in the output of
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --list


/usr/share/man/man1/gcc.1.gz
/usr/share/man/man1/gcov.1.gz
/usr/share/man/man1/protoize.1.gz
/usr/share/man/man1/unprotoize.1.gz

The rpm package "rpm" occurred in the output of
rpm -qa
:
rpm-4.8.0-55.el6.x86_64

So, the man pages for rpm may be included in the rpm package "rpm" and may therefore exist on Kalkin.


Note: While transferring command output in text files from Kalkin to Aineko via memory stick, I have found several times that the text file is blank or only partially copied.
Observations:
- If I use
cat /mnt/test1/work.log | less
to view the file on the mounted filesystem before unmounting it, the entire file is present.
- Avoiding the
cp
utility by using
cat work.log > /mnt/test1/work.log
instead of
cp work.log /mnt/test1/work.log
does not appear to help.
- After unmounting the memory stick's filesystem, mounting it and unmounting it again appears to help.


Anyway, let's proceed.

[root@kalkin work]# rpm --query rpm

rpm-4.8.0-55.el6.x86_64

[root@kalkin work]# rpm --query rpm --list

/bin/rpm
/etc/rpm
/usr/bin/rpm2cpio
/usr/bin/rpmdb
/usr/bin/rpmquery
/usr/bin/rpmsign
/usr/bin/rpmverify
/usr/lib/rpm
/usr/lib/rpm/macros
/usr/lib/rpm/platform
/usr/lib/rpm/platform/amd64-linux
/usr/lib/rpm/platform/amd64-linux/macros
/usr/lib/rpm/platform/athlon-linux
/usr/lib/rpm/platform/athlon-linux/macros
/usr/lib/rpm/platform/geode-linux
/usr/lib/rpm/platform/geode-linux/macros
/usr/lib/rpm/platform/i386-linux
/usr/lib/rpm/platform/i386-linux/macros
/usr/lib/rpm/platform/i486-linux
/usr/lib/rpm/platform/i486-linux/macros
/usr/lib/rpm/platform/i586-linux
/usr/lib/rpm/platform/i586-linux/macros
/usr/lib/rpm/platform/i686-linux
/usr/lib/rpm/platform/i686-linux/macros
/usr/lib/rpm/platform/ia32e-linux
/usr/lib/rpm/platform/ia32e-linux/macros
/usr/lib/rpm/platform/noarch-linux
/usr/lib/rpm/platform/noarch-linux/macros
/usr/lib/rpm/platform/pentium3-linux
/usr/lib/rpm/platform/pentium3-linux/macros
/usr/lib/rpm/platform/pentium4-linux
/usr/lib/rpm/platform/pentium4-linux/macros
/usr/lib/rpm/platform/x86_64-linux
/usr/lib/rpm/platform/x86_64-linux/macros
/usr/lib/rpm/rpm.daily
/usr/lib/rpm/rpm.log
/usr/lib/rpm/rpm.xinetd
/usr/lib/rpm/rpm2cpio.sh
/usr/lib/rpm/rpmdb_archive
/usr/lib/rpm/rpmdb_deadlock
/usr/lib/rpm/rpmdb_dump
/usr/lib/rpm/rpmdb_load
/usr/lib/rpm/rpmdb_loadcvt
/usr/lib/rpm/rpmdb_printlog
/usr/lib/rpm/rpmdb_recover
/usr/lib/rpm/rpmdb_stat
/usr/lib/rpm/rpmdb_upgrade
/usr/lib/rpm/rpmdb_verify
/usr/lib/rpm/rpmpopt-4.8.0
/usr/lib/rpm/rpmrc
/usr/lib/rpm/tgpg
/usr/share/doc/rpm-4.8.0
/usr/share/doc/rpm-4.8.0/COPYING
/usr/share/doc/rpm-4.8.0/CREDITS
/usr/share/doc/rpm-4.8.0/ChangeLog.bz2
/usr/share/doc/rpm-4.8.0/GROUPS
/usr/share/doc/rpm-4.8.0/builddependencies
/usr/share/doc/rpm-4.8.0/buildroot
/usr/share/doc/rpm-4.8.0/conditionalbuilds
/usr/share/doc/rpm-4.8.0/dependencies
/usr/share/doc/rpm-4.8.0/format
/usr/share/doc/rpm-4.8.0/hregions
/usr/share/doc/rpm-4.8.0/macros
/usr/share/doc/rpm-4.8.0/multiplebuilds
/usr/share/doc/rpm-4.8.0/queryformat
/usr/share/doc/rpm-4.8.0/relocatable
/usr/share/doc/rpm-4.8.0/signatures
/usr/share/doc/rpm-4.8.0/spec
/usr/share/doc/rpm-4.8.0/triggers
/usr/share/doc/rpm-4.8.0/tsort
/usr/share/locale/ca/LC_MESSAGES/rpm.mo
/usr/share/locale/cs/LC_MESSAGES/rpm.mo
/usr/share/locale/da/LC_MESSAGES/rpm.mo
/usr/share/locale/de/LC_MESSAGES/rpm.mo
/usr/share/locale/es/LC_MESSAGES/rpm.mo
/usr/share/locale/fi/LC_MESSAGES/rpm.mo
/usr/share/locale/fr/LC_MESSAGES/rpm.mo
/usr/share/locale/is/LC_MESSAGES/rpm.mo
/usr/share/locale/it/LC_MESSAGES/rpm.mo
/usr/share/locale/ja/LC_MESSAGES/rpm.mo
/usr/share/locale/ko/LC_MESSAGES/rpm.mo
/usr/share/locale/ms/LC_MESSAGES/rpm.mo
/usr/share/locale/nb/LC_MESSAGES/rpm.mo
/usr/share/locale/nl/LC_MESSAGES/rpm.mo
/usr/share/locale/pl/LC_MESSAGES/rpm.mo
/usr/share/locale/pt/LC_MESSAGES/rpm.mo
/usr/share/locale/pt_BR/LC_MESSAGES/rpm.mo
/usr/share/locale/ru/LC_MESSAGES/rpm.mo
/usr/share/locale/sk/LC_MESSAGES/rpm.mo
/usr/share/locale/sl/LC_MESSAGES/rpm.mo
/usr/share/locale/sr/LC_MESSAGES/rpm.mo
/usr/share/locale/sr@latin/LC_MESSAGES/rpm.mo
/usr/share/locale/sv/LC_MESSAGES/rpm.mo
/usr/share/locale/tr/LC_MESSAGES/rpm.mo
/usr/share/locale/zh_TW/LC_MESSAGES/rpm.mo
/usr/share/man/fr/man8/rpm.8.gz
/usr/share/man/ja/man8/rpm.8.gz
/usr/share/man/ja/man8/rpm2cpio.8.gz
/usr/share/man/ja/man8/rpmbuild.8.gz
/usr/share/man/ja/man8/rpmgraph.8.gz
/usr/share/man/ko/man8/rpm.8.gz
/usr/share/man/ko/man8/rpm2cpio.8.gz
/usr/share/man/man8/rpm.8.gz
/usr/share/man/man8/rpm2cpio.8.gz
/usr/share/man/pl/man1/gendiff.1.gz
/usr/share/man/pl/man8/rpm.8.gz
/usr/share/man/pl/man8/rpm2cpio.8.gz
/usr/share/man/pl/man8/rpmbuild.8.gz
/usr/share/man/pl/man8/rpmdeps.8.gz
/usr/share/man/pl/man8/rpmgraph.8.gz
/usr/share/man/ru/man8/rpm.8.gz
/usr/share/man/ru/man8/rpm2cpio.8.gz
/usr/share/man/sk/man8/rpm.8.gz
/var/lib/rpm
/var/lib/rpm/Basenames
/var/lib/rpm/Conflictname
/var/lib/rpm/Dirnames
/var/lib/rpm/Filedigests
/var/lib/rpm/Group
/var/lib/rpm/Installtid
/var/lib/rpm/Name
/var/lib/rpm/Obsoletename
/var/lib/rpm/Packages
/var/lib/rpm/Providename
/var/lib/rpm/Provideversion
/var/lib/rpm/Pubkeys
/var/lib/rpm/Requirename
/var/lib/rpm/Requireversion
/var/lib/rpm/Sha1header
/var/lib/rpm/Sigmd5
/var/lib/rpm/Triggername
/var/lib/rpm/__db.001
/var/lib/rpm/__db.002
/var/lib/rpm/__db.003
/var/lib/rpm/__db.004
/var/lib/rpm/__db.005
/var/lib/rpm/__db.006
/var/lib/rpm/__db.007
/var/lib/rpm/__db.008
/var/lib/rpm/__db.009

[root@kalkin work]# rpm --query rpm --list | grep man

/usr/share/man/fr/man8/rpm.8.gz
/usr/share/man/ja/man8/rpm.8.gz
/usr/share/man/ja/man8/rpm2cpio.8.gz
/usr/share/man/ja/man8/rpmbuild.8.gz
/usr/share/man/ja/man8/rpmgraph.8.gz
/usr/share/man/ko/man8/rpm.8.gz
/usr/share/man/ko/man8/rpm2cpio.8.gz
/usr/share/man/man8/rpm.8.gz
/usr/share/man/man8/rpm2cpio.8.gz
/usr/share/man/pl/man1/gendiff.1.gz
/usr/share/man/pl/man8/rpm.8.gz
/usr/share/man/pl/man8/rpm2cpio.8.gz
/usr/share/man/pl/man8/rpmbuild.8.gz
/usr/share/man/pl/man8/rpmdeps.8.gz
/usr/share/man/pl/man8/rpmgraph.8.gz
/usr/share/man/ru/man8/rpm.8.gz
/usr/share/man/ru/man8/rpm2cpio.8.gz
/usr/share/man/sk/man8/rpm.8.gz



I think that:
- fr = French
- ja = Japanese
- ko = Korean
- pl = Polish
- ru = Russian
- sk = [a Scandinavian language]

This leaves two files that are probably in English:
/usr/share/man/man8/rpm.8.gz
/usr/share/man/man8/rpm2cpio.8.gz


Some reading indicates that rpm2cpio is a tool for extracting files from an rpm package.

This leaves
/usr/share/man/man8/rpm.8.gz
as the candidate for being the rpm man page supplied with this version of rpm.

The .gz extension indicates that this a gzip file.


Is gzip available on Kalkin?


[root@kalkin work]# which gzip

/bin/gzip

[root@kalkin work]# rpm -qa gzip

gzip-1.3.12-24.el6.x86_64



Yes.

I'll unzip it before I transfer it to Aineko.


[root@kalkin work]# cp /usr/share/man/man8/rpm.8.gz rpm.8.gz


[root@kalkin work]# gunzip rpm.8.gz


[root@kalkin work]# ls -1

archived
rpm.8
rpms
work.log

[root@kalkin work]# file rpm.8

rpm.8: troff or preprocessor input text



cat rpm.8 | less
shows that the preprocessor input text is somewhat readable.

Transfer rpm.8 to Aineko.

Open rpm.8 in TextWrangler.

Search for "conflicts".

One occurrence:

\fB--test\fR
Do not install the package, simply check for and report
potential conflicts.



Hm.


I'm going to assume that "gdb < 5.1-2" is an extra warning, which says that if you wish to use gdb with gcc 4.4.7-18, gdb must be version 5.1-2 or higher.

The --conflicts flag did not report any filepath conflicts.





I'll copy the output of
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --provides

here for ease of reference:

[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --provides

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
gcc = 4.4.4-15.el6
gcc = 4.4.7-18.el6
gcc(x86-64) = 4.4.7-18.el6


Perhaps gcc-4.4.7-18.el6.x86_64.rpm also includes gcc 4.4.4-15 (invoked via command-line option?).

gcc(x86-64)
may indicate that this version of gcc can be used to target the x86-64 architecture.

Note: these items aren't file paths:
- gcc
- gcc(x86-64)


I'll copy the output of
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --requires

here for ease of reference:

[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --requires

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
/bin/sh
/bin/sh
/bin/sh
/sbin/install-info
/sbin/install-info
binutils >= 2.19.51.0.14-33
cloog-ppl >= 0.15
cpp = 4.4.7-18.el6
glibc-devel >= 2.2.90-12
libc.so.6()(64bit)
libc.so.6(GLIBC_2.11)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libgcc >= 4.4.7-18.el6
libgcc_s.so.1()(64bit)
libgomp = 4.4.7-18.el6
libgomp.so.1()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1



/bin/sh appears 3 times.
/sbin/install-info appears 2 times.
why?

rpmlib is evidently a dependency, but I don't understand the various items in brackets (), e.g.
- rpmlib(CompressedFileNames)
- rpmlib(FileDigests)
Are they sub-dependencies?


Notably, the following items are not file paths:
- binutils
- cloog-ppl
- cpp
- glibc-devel
- libc.so.6
- libgcc
- libgcc_s.so.1
- libgomp
- libgomp.so.1
- rpmlib
- rtld


This line:
"binutils >= 2.19.51.0.14-33"
suggests a package named "binutils" of version 2.19.51.0.14-33 or higher.


I don't know what the .so.1 and .so.6 extensions signify.


The ordering and naming of these two items:
- libgomp = 4.4.7-18.el6
- libgomp.so.1()(64bit)
suggests that libgomp.so.1 is a file within the libgomp package. "()(64bit)" would then be a descriptor sequence that describes this file in some way.


The ordering and naming of these items:
- glibc-devel >= 2.2.90-12
- libc.so.6()(64bit)
- libc.so.6(GLIBC_2.11)(64bit)
- libc.so.6(GLIBC_2.2.5)(64bit)
suggests that the first bracketed descriptor can be empty or can specify a particular earlier version of the package.
The second bracketed descriptor can specify that the code is targeted at a 64-bit CPU.


These items:
- rpmlib(CompressedFileNames) <= 3.0.4-1
- rpmlib(FileDigests) <= 4.6.0-1
suggest that the first bracketed descriptor can specify a subelement of the package (rather than a version of the package) and that the second bracketed descriptor does not have to exist. The version numbers presumably specify versions of the package subelements.

This item:
- rtld(GNU_HASH)
shows that there can be a single bracketed descriptor that specifies a package subelement, for which no version number is specified.


Note:
rpm --query --file [filepath]
requires a filepath. If used with a filename or relative filepath, it will prepend the current working directory to the file name/path.


[root@kalkin work]# rpm --query --file /bin/sh

bash-4.1.2-48.el6.x86_64

[root@kalkin work]# rpm --query --file /sbin/install-info

info-4.13a-8.el6.x86_64

[root@kalkin work]# rpm --query binutils

binutils-2.20.51.0.2-5.46.el6.x86_64

[root@kalkin work]# rpm --query cloog-ppl

package cloog-ppl is not installed

[root@kalkin work]# rpm --query cpp

package cpp is not installed

[root@kalkin work]# rpm --query glibc-devel

package glibc-devel is not installed

[root@kalkin work]# rpm --query glibc

glibc-2.12-1.209.el6.x86_64

[root@kalkin work]# rpm --query libgcc

libgcc-4.4.7-18.el6.x86_64

[root@kalkin work]# rpm --query libgomp

package libgomp is not installed

[root@kalkin work]# rpm --query rpmlib

package rpmlib is not installed

[root@kalkin work]# rpm --query rtld

package rtld is not installed



/bin/sh and /sbin/install-info are present.

binutils: 2.20.51.0.2-5.46 is a greater version number than 2.19.51.0.14-33, so this dependency is satisfied.

glibc: 2.12-1.209 is greater than 2.2.90-12, but the requirements specify glibc-devel, which is almost certainly not the same item as glibc.

libgcc: 4.4.7-18 is the same as 4.4.7-18, so this dependency is satisfied.


I had thought that the requirements would be either files (in particular paths) or packages. However, "rtld(GNU_HASH)" might be something entirely different - a different category that exists between the categories of package and file.

[root@kalkin work]# rpm --query rtld(GNU_HASH)

-bash: syntax error near unexpected token `('

[root@kalkin work]# rpm --query rtld\(GNU_HASH\)

package rtld(GNU_HASH) is not installed



How do I determine the name of the package that contains the item "rtld(GNU_HASH)"? Is it "rtld"?


Regarding package requirements:

- If a package is required, I can query the rpm database using the package's short name (e.g. "glibc") to see if it is listed. The full package name (e.g. "glibc-2.12-1.209.el6.x86_64") will contain its version number. If the rpm database doesn't have an entry for the package, then I can search on package mirror sites for the package name.

- If a file is required, I can check if it exists on the filesystem. I can query the rpm database using the --file flag to see which package it belongs to. If the rpm database doesn't have an entry for it, then [some checking occurs here] it appears to be possible to search on some package mirror sites for the filepath, and discover which package contains it.

However, if an item such as rtld(GNU_HASH) is required, where and how can I look it up?
The same applies to "libc.so.6".



Let's try searching for "rtld(GNU_HASH)" on a mirror site:
pkgs.org
This returns, among other packages,
"glibc-2.12-1.209.el6.x86_64.rpm - The GNU libc libraries"
which suggests that rtld(GNU_HASH) is part of glibc.

Searching for "libc.so.6" on
pkgs.org
returns, among other packages,
"glibc-2.12-1.209.el6.i686.rpm - The GNU libc libraries"
which suggests that libc.so.6 is part of glibc.

The search results are entitled "Search on Name and Provides".
This suggests that --provides or --whatprovides options may help.

What is libc.so.6?


Excerpts from:
ftp.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html
Title: Maximum RPM
Authors:
- Edward C. Bailey
- Paul Nasrat
- Matthias Saou
- Ville Skyttä


Chapter 14. Adding Dependency Information to a Package


Automatic Dependencies

When a package is built by RPM, if any file in the package's
%files
list is a shared library, the library's soname is automatically added to the list of capabilities the package provides. The soname is the name used to determine compatibility between different versions of a library.

Note that this is not a filename. In fact, no aspect of RPM's dependency processing is based on filenames. Many people new to RPM often make the assumption that a failed dependency represents a missing file. This is not the case.

Remember that RPM's dependency processing is based on knowing what capabilities are provided by a package and what capabilities a package requires. We've seen how RPM automatically determines what shared library resources a package provides. But does it automatically determine what shared libraries a package requires?

Yes! RPM does this by running
ldd
on every executable program in a package's
%files
list. Since
ldd
provides a list of the shared libraries each program requires, both halves of the equation are complete - that is, the packages that make shared libraries available, and the packages that require those shared libraries, are tracked by RPM. RPM can then take that information into account when packages are installed, upgraded, or erased.

[...]

The find-requires script for Linux is quite simple.

[...]

This script first creates a list of executable files. Then, for each file in the list,
ldd
determines the file's shared library requirements, producing a list of sonames. Finally, the list of sonames is sanitized by removing duplicates, and removing any paths.

[...]

The find-provides script for Linux is a bit more complex, but still pretty straightforward:

[...]

First, a list of shared libraries is created. Then, for each file on the list, the soname is extracted, cleaned up, and duplicates removed.



I am surprised to find out that RPM's dependency processing is based on "capabililities", rather than filepaths.


Here's our intermediate category: "capability" i.e. a shared library.

The capabilities of a package are derived from examining the files within it that are executable and/or are shared libraries.

It looks as though when a executable file is compiled from source code, it includes the names of the shared libraries that it depends on.
- These names are "sonames" and presumably have this sort of format: "libc.so.6"
- The
ldd
tool can extract the names of these shared libraries.
This is used in the construction of the --requires list.

It also looks as though a shared library file contains details that declare it to be a shared library file.
- The list of files within a package is examined, and a list is made of those that are shared libraries. From each shared library, the soname is extracted.
This is used in the construction of the --provides list.

Note (from the output of the --requires option) that shared library files have versions, and that these version can be specified in a package's requirements.



I'd like to be able to query the rpm database to find out, for each shared library dependency, what package provides this dependency, or if no installed package provides it. I'll investigate the use of the --whatprovides option.

--whatprovides = query/verify the package(s) which provide a dependency




[root@kalkin work]# rpm --query --whatprovides /bin/sh

bash-4.1.2-48.el6.x86_64

[root@kalkin work]# rpm --query --whatprovides /sbin/install-info

info-4.13a-8.el6.x86_64

[root@kalkin work]# rpm --query --whatprovides binutils

binutils-2.20.51.0.2-5.46.el6.x86_64

[root@kalkin work]# rpm --query --whatprovides cloog-ppl

no package provides cloog-ppl

[root@kalkin work]# rpm --query --whatprovides cpp

no package provides cpp

[root@kalkin work]# rpm --query --whatprovides glibc-devel

no package provides glibc-devel

[root@kalkin work]# rpm --query --whatprovides libc.so.6

no package provides libc.so.6

[root@kalkin work]# rpm --query --whatprovides libc.so.6\(\)\(64bit\)

glibc-2.12-1.209.el6.x86_64

[root@kalkin work]# rpm --query --whatprovides libc.so.6\(GLIBC_2.11\)\(64bit\)

glibc-2.12-1.209.el6.x86_64

[root@kalkin work]# rpm --query --whatprovides libc.so.6\(GLIBC_2.2.5\)\(64bit\)

glibc-2.12-1.209.el6.x86_64

[root@kalkin work]# rpm --query --whatprovides libc.so.6\(GLIBC_2.3\)\(64bit\)

glibc-2.12-1.209.el6.x86_64

[root@kalkin work]# rpm --query --whatprovides libc.so.6\(GLIBC_2.4\)\(64bit\)

glibc-2.12-1.209.el6.x86_64

[root@kalkin work]# rpm --query --whatprovides libc.so.6\(GLIBC_2.7\)\(64bit\)

glibc-2.12-1.209.el6.x86_64

[root@kalkin work]# rpm --query --whatprovides libgcc

libgcc-4.4.7-18.el6.x86_64

[root@kalkin work]# rpm --query --whatprovides libgcc_s.so.1\(\)\(64bit\)

libgcc-4.4.7-18.el6.x86_64

[root@kalkin work]# rpm --query --whatprovides libgomp

no package provides libgomp

[root@kalkin work]# rpm --query --whatprovides libgomp.so.1\(\)\(64bit\)

no package provides libgomp.so.1()(64bit)

[root@kalkin work]# rpm --query --whatprovides rpmlib

no package provides rpmlib

[root@kalkin work]# rpm --query --whatprovides rpmlib\(CompressedFileNames\)

no package provides rpmlib(CompressedFileNames)

[root@kalkin work]# rpm --query --whatprovides rpmlib\(FileDigests\)

no package provides rpmlib(FileDigests)

[root@kalkin work]# rpm --query --whatprovides rpmlib\(PartialHardlinkSets\)

no package provides rpmlib(PartialHardlinkSets)

[root@kalkin work]# rpm --query --whatprovides rpmlib\(PayloadFilesHavePrefix\)

no package provides rpmlib(PayloadFilesHavePrefix)

[root@kalkin work]# rpm --query --whatprovides rpmlib\(VersionedDependencies\)

no package provides rpmlib(VersionedDependencies)

[root@kalkin work]# rpm --query --whatprovides rpmlib\(PayloadIsXz\)

no package provides rpmlib(PayloadIsXz)

[root@kalkin work]# rpm --query --whatprovides rtld

no package provides rtld

[root@kalkin work]# rpm --query --whatprovides rtld\(GNU_HASH\)

glibc-2.12-1.209.el6.x86_64



These files are present:
/bin/sh [in package bash-4.1.2-48.el6.x86_64]
/sbin/install-info [in package info-4.13a-8.el6.x86_64]

These packages are installed:
binutils-2.20.51.0.2-5.46.el6.x86_64 [required: binutils >= 2.19.51.0.14-33]
libgcc-4.4.7-18.el6.x86_64 [required: libgcc >= 4.4.7-18.el6]

These shared libraries are installed:
libc.so.6()(64bit) [in package glibc-2.12-1.209.el6.x86_64]
libc.so.6(GLIBC_2.11)(64bit) [in package glibc-2.12-1.209.el6.x86_64]
libc.so.6(GLIBC_2.2.5)(64bit) [in package glibc-2.12-1.209.el6.x86_64]
libc.so.6(GLIBC_2.3)(64bit) [in package glibc-2.12-1.209.el6.x86_64]
libc.so.6(GLIBC_2.4)(64bit) [in package glibc-2.12-1.209.el6.x86_64]
libc.so.6(GLIBC_2.7)(64bit) [in package glibc-2.12-1.209.el6.x86_64]
libgcc_s.so.1()(64bit) [in package libgcc-4.4.7-18.el6.x86_64]

This item is present:
rtld(GNU_HASH) [in package glibc-2.12-1.209.el6.x86_64]
-> I don't think it's a shared library. It looks like another type of item.

These packages are not installed:
cloog-ppl >= 0.15
cpp = 4.4.7-18.el6
glibc-devel >= 2.2.90-12
libgomp = 4.4.7-18.el6

These shared libraries are not installed:
libgomp.so.1()(64bit) [probably provided by package libgomp = 4.4.7-18.el6]

These items are not present:
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rpmlib(PayloadIsXz) <= 5.2-1
-> I don't think these are shared libraries. They look like another type of item.



I think that these items:
- rtld(GNU_HASH)
- rpmlib(CompressedFileNames) <= 3.0.4-1
- rpmlib(FileDigests) <= 4.6.0-1
- rpmlib(PartialHardlinkSets) <= 4.0.4-1
- rpmlib(PayloadFilesHavePrefix) <= 4.0-1
- rpmlib(VersionedDependencies) <= 3.0.3-1
- rpmlib(PayloadIsXz) <= 5.2-1
are something other than shared libraries / package capabilities, because the shared libraries
e.g. libc.so.6(GLIBC_2.11)(64bit)
1) have an extension such as ".so.1" or ".so.6"
2) are followed by two pairs of brackets (), the first of which optionally specifies the version of the shared library e.g. () or (GLIBC_2.11), and the second of which specifies the CPU architecture type (64bit)

I suspect that "so" in "soname" stands for "shared object".



Let's read some more of the book Maximum RPM.

Excerpt from:
ftp.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html

Chapter 14. Adding Dependency Information to a Package


Manual Dependencies

You might have noticed that we've been using the words "requires" and "provides" to describe the dependency relationships between packages. As it turns out, these are the exact words used in spec files to manually add dependency information. Let's look at the first tag: Requires.


The Requires Tag

We've been deliberately vague when discussing exactly what it is that a package requires. Although we've used the word "capabilities", in fact, manual dependency requirements are always represented in terms of packages. For example, if package
foo
requires that package
bar
is installed, it's only necessary to add the following line to
foo
's spec file:

Requires: bar


Later, when the
foo
package is being installed, RPM will consider
foo
's dependency requirements met if any version of package
bar
is already installed.

If more than one package is required, they can be added to the Requires tag, one after another, separated by commas and/or spaces. So if package
foo
requires packages
bar
and
baz
, the following line will do the trick:

Requires: bar, baz


As long as any version of
bar
and
baz
is installed,
foo
's dependencies will be met.


Adding Version Requirements

When a package has slightly more stringent needs, it's possible to require certain versions of a package. All that's necessary is to add the desired version number, preceded by one of the following comparison operators:

- Requires package with a version less than the specified version.
- Requires package with a version less than or equal to the specified version.
- Requires package with a version equal to the specified version.
- Requires package with a version equal to or greater than the specified version.
- Requires package with a version greater than the specified version.

Continuing with our example, let's suppose that the required version of package
bar
actually needs to be at least 2.7, and that the
baz
package must be version 2.1 - no other version will do. Here's what the Requires tag line would look like:

Requires: bar >= 2.7, baz = 2.1


We can get even more specific and require a particular release of a package:

Requires: bar >= 2.7-4, baz = 2.1-1



bar
is similar to rtld(GNU_HASH), with (GNU_HASH) as an addition to the name.

bar >= 2.7-4
is similar to rpmlib(CompressedFileNames) <= 3.0.4-1, with (CompressedFileNames) as an addition to the name.



Note: The following excerpt explains the meaning of the item "gdb < 5.1-2" in the output of
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --conflicts
.

Excerpt from:
ftp.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html

The Conflicts Tag

The Conflicts tag is the logical complement to the Requires tag. It is used to specify which packages conflict with the current package. RPM will not permit conflicting packages to be installed unless overridden with the
--nodeps
option.


So any version of the package gdb that is below version 5.1-2 will conflict with the package gcc-4.4.7-18.


Searching on
pkgs.org
for "rpmlib(CompressedFileNames)"
with Distribution = Centos 6
results in "No packages found."

Searching on
pkgs.org
for "rpmlib"
with Distribution = Centos 6
results in:
- EPEL i386, kobo-rpmlib-0.6.0-1.el6.noarch.rpm, Functions to manipulate with RPM files
- EPEL x86_64, kobo-rpmlib-0.6.0-1.el6.noarch.rpm, Functions to manipulate with RPM files





Excerpt from:
rpm.org/user_doc/more_dependencies.html

Interpreters and Shells

Modules for interpreted languages like perl and tcl impose additional dependency requirements on packages. A script written for an interpreter often requires language specific modules to be installed in order to execute correctly. In order to automatically detect language specific modules, each interpreter may have its own generators. To prevent module name collisions between interpreters, module names are enclosed within parentheses and a conventional interpreter specific identifier is prepended:

Provides: perl(MIME-Base64), perl(Mail-Header)-1-09

Requires: perl(Carp), perl(IO-Wrap) = 4.5


The output of a per-interpreter dependency generator (notice in this example the first requirement is a package and the rest are language specific modules)

Mail-Header >= 1.01
perl(Carp) >= 3.2
perl(IO-Wrap) == 4.5 or perl(IO-Wrap)-4.5



This excerpt indicates that there exists another type of dependency: an interpreted language module (and optionally its version number).

Then perhaps these items are modules:
- rtld(GNU_HASH)
- rpmlib(CompressedFileNames) <= 3.0.4-1
- rpmlib(FileDigests) <= 4.6.0-1
- rpmlib(PartialHardlinkSets) <= 4.0.4-1
- rpmlib(PayloadFilesHavePrefix) <= 4.0-1
- rpmlib(VersionedDependencies) <= 3.0.3-1
- rpmlib(PayloadIsXz) <= 5.2-1

Although:
- "rpmlib" sounds like a library, not like an interpreted language.
- rtld is provided by glibc-2.12-1.209, which is a package, suggesting that rtld is a shared library item.

Perhaps this format convention does not apply only to modules for interpreted languages, but also to functions/modules within shared library items.

So, this would indicate that, for example:
- rtld(GNU_HASH) specifies that the GNU_HASH module of the rtld item is a requirement.
- rpmlib(CompressedFileNames) <= 3.0.4-1 specifies that the CompressedFileNames module within the rpmlib shared library is a requirement, and that its version must be no higher than 3.0.4-1.

rtld(GNU_HASH) is already provided. No version number is specified, so this dependency is presumably satisfied.


Excerpt from:
www.redhat.com/archives/rhl-beta-list/2009-August/msg00290.html
Author: Michael Schwendt
Subject: Re: rpmlib(PayloadIsXz) <= 5.2-1 is needed by ?????
Date: Tue, 11 Aug 2009 09:17:54 +0200

RPM is built as multiple packages, most important is "rpm-libs".




Email thread:
www.redhat.com/archives/rpm-list/2001-April/msg00280.html
www.redhat.com/archives/rpm-list/2001-April/msg00283.html
www.redhat.com/archives/rpm-list/2001-April/msg00294.html

From: "Tim Bartley" <tbartley au1 ibm com>
To: rpm-list redhat com
Subject: rpmlib(VersionedDependencies) <= 3.0.3-1
Date: Thu, 26 Apr 2001 10:15:43 +1000

Hi,

I''m building a package to which I just added a versioned dependency. Now, the following additional dependency appears to be automatically created as well:

rpmlib(VersionedDependencies) <= 3.0.3-1

Consequently my package fails to install on versions of Linux with later versions of RPM whereas before adding my versioned dependency it installed fine.

Is this a bug in the version of RPM I'm using (should the dependency be >= 3.0.3-1)? Or do I just not understand why it makes sense to only be able to install packages with earlier versions of RPM rather than later versions? This seems backwards to me.

# rpm --version
RPM version 3.0.5

I also don't seem to be able to find out what version of rpmlib(VersionedDependencies) is provided on a system e.g.

# rpm -q --provides 'rpmlib(VersionedDependencies)'
package rpmlib(VersionedDependencies) is not installed
# rpm -q --provides rpmlib
package rpmlib is not installed

I am an RPM newbie so I'm probably just missing something fundamental here. Can someone explain to me how I can get around this? Do I simply have to remove my own versioned dependency so this goes away? How are versioned dependencies supposed to be used? It seems to me that they're not useful if they always bring in this '<= <some RPM version>' restriction (which is how I interpret the above). I want to be able to specify a version rather than just the package because I know earlier versions of the package I prereq are broken.

Cheers,

Tim Bartley.
--
Senior Software Engineer
Tivoli Systems
Gold Coast Development Lab, Australia
+61-7-5552-4001 phone
+61-7-5571-0420 fax





From: Jeff Johnson <jbj JBJ ORG>
To: rpm-list redhat com
Subject: Re: rpmlib(VersionedDependencies) <= 3.0.3-1
Date: Thu, 26 Apr 2001 08:15:32 -0400

On Thu, Apr 26, 2001 at 10:15:43AM +1000, Tim Bartley wrote:

Hi,

I''m building a package to which I just added a versioned dependency. Now, the following additional dependency appears to be automatically created as well:
rpmlib(VersionedDependencies) <= 3.0.3-1


Yup. The dependency is tracking the use of syntax that will create a package that won't work quite right with versions of rpm before 3.0.3.


Consequently my package fails to install on versions of Linux with later versions of RPM whereas before adding my versioned dependency it installed fine.


Hmmm, details please. How does your package "fail to install"? Yes, the dependency fails with rpm < 3.0.5, upgrade to rpm-3.0.5, or, if the only failure, use --nodeps.

Is this a bug in the version of RPM I'm using (should the dependency be >= 3.0.3-1)? Or do I just not understand why it makes sense to only be able to install packages with earlier versions of RPM rather than later versions? This seems backwards to me.


Not a bug. The dependency is written with <= so that the range is closed, as >= would make the implicit promise "forever". Meanwhile, since the matching capability is

Provides: rpmlib(VersionedDependencies) = 3.0.3-1

there's only a single point covered by the overlapping dependency ranges.


# rpm --version
RPM version 3.0.5

I also don't seem to be able to find out what version of rpmlib(VersionedDependencies) is provided on a system e.g.

# rpm -q --provides 'rpmlib(VersionedDependencies)'
package rpmlib(VersionedDependencies) is not installed
# rpm -q --provides rpmlib
package rpmlib is not installed


Yup. rpm --showrc displays the internal dependencies, provided by rpmlib itself, not by a package:

... Features supported by rpmlib: rpmlib(VersionedDependencies) = 3.0.3-1 PreReq:, Provides:, and Obsoletes: dependencies support versions. rpmlib(CompressedFileNames) = 3.0.4-1 file names stored as (dirName,baseName,dirIndex) tuple, not as path. rpmlib(PayloadIsBzip2) = 3.0.5-1 package payload compressed using bzip2. rpmlib(PayloadFilesHavePrefix) = 4.0-1 package payload files have "./" prefix. rpmlib(ExplicitPackageProvide) = 4.0-1 package name-version-release not implicitly provided. rpmlib(HeaderLoadSortsTags) = 4.0.1-1 header tags are always sorted after being loaded. ...



I am an RPM newbie so I'm probably just missing something fundamental here. Can someone explain to me how I can get around this? Do I simply have to remove my own versioned dependency so this goes away? How are versioned dependencies supposed to be used? It seems to me that they're not useful if they always bring in this '<= <some RPM version>' restriction (which is how I interpret the above). I want to be able to specify a version rather than just the package because I know earlier versions of the package I prereq are broken.


The dependency is not the problem, the underlying incompatibility being tracked in legacy versions of rpm is the problem. rpmlib(...) dependencies are not for general use, they try to insure that packages are installed by a version of rpm that can handle the packaging.

73 de Jeff

--
Jeff Johnson ARS N3NPQ
jbj@jbj.org (jbj@redhat.com)
Chapel Hill, NC





From: "Tim Bartley" <tbartley au1 ibm com>
To: rpm-list redhat com
Subject: Re: rpmlib(VersionedDependencies) <= 3.0.3-1
Date: Fri, 27 Apr 2001 13:46:37 +1000

Jeff Johnson wrote:
Consequently my package fails to install on versions of Linux with later versions of RPM whereas before adding my versioned dependency it installed fine.


Hmmm, details please. How does your package "fail to install"? Yes, the dependency fails with rpm < 3.0.5, upgrade to rpm-3.0.5, or, if the only failure, use --nodeps.



My mistake. I assumed that because the dependency check failed that the RPM version was greater (I understand that the rpmlib(VersionedDependencies) version is like an interface or data format version essentially independent of the version of RPM installed on a system). Once I was able to get on to the machine where the install was failing I discovered the version of RPM being used was 3.0.4 on a vanilla RedHat 6.2 system.

Thanks for your help.

Cheers,

Tim Bartley




Hm.


Key points and thoughts:
- "rpmlib(...) dependencies are not for general use, they try to insure that packages are installed by a version of rpm that can handle the packaging."
- The dependency { rpmlib(VersionedDependencies) <= 3.0.3-1 } was automatically created when Tim Bartley built a package. He had added a versioned dependency to the package.
- He then attempted to install this package on a vanilla RedHat 6.2 system using rpm 3.0.4. This installation failed.
- Jeff Johnson said that the installation will fail if attempted with rpm < 3.0.5 and succeed if attempted with rpm 3.0.5.
- rpmlib is not a package or a shared library / capability. It is internal to rpm. It can change as rpm goes through version changes. It is involved in tracking backwards-incompatible changes in the way that rpm handles packages.
- rpm --showrc displays the internal dependencies.
- All this seems to suggest that { rpmlib(VersionedDependencies) <= 3.0.3-1 } specifies that the version of rpm must be > 3.0.3-1.
- This is an odd syntax. The explanation offered is: { The dependency is written with <= so that the range is closed, as >= would make the implicit promise "forever". }. It is then a negative claim - "dependency should be any version that is not in the specified range".
-- Also, the dependency should technically work with rpm 3.0.3-1, but this point in the version number range is included within the excluded section via { <= 3.0.3-1 }, so that the range end point is a definitive version number in particular (i.e. "closed range").
- Jeff Johnson may have extra information that allows him to know that this particular dependency will also fail if rpm = 3.0.4 and therefore rpm must be >= 3.0.5.
- Ah. Here {
# rpm --version
RPM version 3.0.5
}, I see that on Tim Bartley's package build system, rpm 3.0.5 was installed. That's where "3.0.5" comes from. I don't know why the generated negative-range rpmlib dependency { rpmlib(VersionedDependencies) <= 3.0.3-1 } specifies version number 3.0.3-1 but actually won't work unless the rpm version is 3.0.5 (the build system rpm version) or greater. (why won't it work when rpm version = 3.0.4?)
- Hm. In the rpm --showrc output, specific rpm version numbers are listed with each dependency { rpmlib(VersionedDependencies) = 3.0.3-1 }. It looks like this means something like "in this rpm installation, the dependency rpmlib(VersionedDependencies) is available, and its version is that which was first included in rpm in rpm version 3.0.3-1". As Jeff Johnson notes, this dependency point overlaps with the dependency range { rpmlib(VersionedDependencies) <= 3.0.3-1 } (at the value 3.0.3-1).




Well, I'll run
rpm --showrc
on Kalkin and see what it produces.

Note: Earlier, I found that Kalkin's version of rpm is 4.8.0.



[root@kalkin ~]# rpm --showrc

ARCHITECTURE AND OS: build arch : x86_64 compatible build archs: x86_64 noarch build os : Linux compatible build os's : Linux install arch : x86_64 install os : Linux compatible archs : x86_64 amd64 em64t athlon noarch i686 i586 i486 i386 fat compatible os's : Linux RPMRC VALUES: optflags : -O2 -g Features supported by rpmlib: rpmlib(BuiltinLuaScripts) = 4.2.2-1 rpmlib(CompressedFileNames) = 3.0.4-1 rpmlib(ConcurrentAccess) = 4.1-1 rpmlib(ExplicitPackageProvide) = 4.0-1 rpmlib(FileCaps) = 4.6.1-1 rpmlib(FileDigests) = 4.6.0-1 rpmlib(HeaderLoadSortsTags) = 4.0.1-1 rpmlib(PartialHardlinkSets) = 4.0.4-1 rpmlib(PayloadFilesHavePrefix) = 4.0-1 rpmlib(PayloadIsBzip2) = 3.0.5-1 rpmlib(PayloadIsLzma) = 4.4.2-1 rpmlib(PayloadIsXz) = 5.2-1 rpmlib(ScriptletInterpreterArgs) = 4.0.3-1 rpmlib(TildeInVersions) = 4.10.0-1 rpmlib(VersionedDependencies) = 3.0.3-1


[rest of output not included]




rpmlib(...) dependencies supported in this rpm 4.8.0:
- rpmlib(BuiltinLuaScripts) = 4.2.2-1
- rpmlib(CompressedFileNames) = 3.0.4-1
- rpmlib(ConcurrentAccess) = 4.1-1
- rpmlib(ExplicitPackageProvide) = 4.0-1
- rpmlib(FileCaps) = 4.6.1-1
- rpmlib(FileDigests) = 4.6.0-1
- rpmlib(HeaderLoadSortsTags) = 4.0.1-1
- rpmlib(PartialHardlinkSets) = 4.0.4-1
- rpmlib(PayloadFilesHavePrefix) = 4.0-1
- rpmlib(PayloadIsBzip2) = 3.0.5-1
- rpmlib(PayloadIsLzma) = 4.4.2-1
- rpmlib(PayloadIsXz) = 5.2-1
- rpmlib(ScriptletInterpreterArgs) = 4.0.3-1
- rpmlib(TildeInVersions) = 4.10.0-1
- rpmlib(VersionedDependencies) = 3.0.3-1



Let's compare this with the rpmlib dependencies listed in the gcc package:
- rpmlib(CompressedFileNames) <= 3.0.4-1
- rpmlib(FileDigests) <= 4.6.0-1
- rpmlib(PartialHardlinkSets) <= 4.0.4-1
- rpmlib(PayloadFilesHavePrefix) <= 4.0-1
- rpmlib(VersionedDependencies) <= 3.0.3-1
- rpmlib(PayloadIsXz) <= 5.2-1


None of the required rpmlib dependencies are missing from the output of --showrc.

In each case, the required dependency in the package uses the same version number as that shown within the output of --showrc.

I conclude that the version number signifies the rpm version in which the rpmlib dependency was introduced.

From reading the email chain above, the only remaining problem is that in order to use an rpmlib dependency, it appears that the version of rpm must be at least one or two versions greater than the version of rpm in which the rpmlib dependency was introduced.
e.g. 3.0.5 instead of 3.0.3-1.

My rpm version is 4.8.0, which is comfortably higher than the version numbers of the following dependencies:
- rpmlib(CompressedFileNames) <= 3.0.4-1
- rpmlib(PartialHardlinkSets) <= 4.0.4-1
- rpmlib(PayloadFilesHavePrefix) <= 4.0-1
- rpmlib(VersionedDependencies) <= 3.0.3-1

two version numbers higher than the version number of this dependency:
- rpmlib(FileDigests) <= 4.6.0-1

and lower than the version number of this dependency:
- rpmlib(PayloadIsXz) <= 5.2-1


When I attempt to install the gcc package, the rpmlib(PayloadIsXz) may cause problems. The solution will presumably be to upgrade rpm to at least version 5.3 or 5.4.


However, strangely, the output of --showrc for rpm 4.8.0 lists this:
rpmlib(PayloadIsXz) = 5.2-1
as a provided rpmlib dependency, suggesting that this requirement may be satisfied. In this instance, I don't know what the number is supposed to mean.



Excerpt from:
stackoverflow.com/questions/25775285/rpmlibfiledigests-dependency-error-on-suse

[comment] If you see a
Requires:
line in a spec file that lists
rpmlib
lines like that I'd be very surprised. To the best of my knowledge those are automatic requirements added by rpm when it creates the package based on the rpmlib features it has used. So
rpmlib(PayloadIsXz)
, for example, means the contents of the rpm package are compressed with
xz
rather than
gzip
.
- Etan Reisner Sep 10 '14 at 21:44



Perhaps 5.2-1, in this case, refers to the version of the xz tool, rather than to the version of rpm in which the rpmlib(PayloadIsXz) capability was added?


[root@kalkin ~]# rpm --query --all | grep rpm

rpm-4.8.0-55.el6.x86_64
rpm-libs-4.8.0-55.el6.x86_64
rpm-python-4.8.0-55.el6.x86_64

[root@kalkin ~]# rpm --query --all | grep xz

xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64



Hm.

There's a package for rpm itself: rpm-4.8.0-55.el6.x86_64

Note the presence of a package, rpm-libs-4.8.0-55.el6.x86_64, that probably contains the code used to provide these capabilities for rpm:
- rpmlib(BuiltinLuaScripts) = 4.2.2-1
- rpmlib(CompressedFileNames) = 3.0.4-1
- rpmlib(ConcurrentAccess) = 4.1-1
[etc]

The presence of the package xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64 indicates that xz is a separate library item, relied on by rpm for the rpmlib(PayloadIsXz) capability, but not actually stored within rpm-libs.

4.999.9-0.5 is lower than 5.2-1.

I think I'll leave the { rpmlib(PayloadIsXz) <= 5.2-1 } vs { rpm 4.8.0 } version number issue alone for now.




Excerpts from:
stackoverflow.com/questions/33768793/rpmlibfiledigests-dependency-error-on-rpm-built-with-rpm-maven-plugin

CentOS 5 and CentOS 6 have wildly different versions of rpm (and rpmlib) and the CentOS 6 version has support for newer payload compression and a newer
FileDigests
version than the version of rpm (and rpmlib) on CentOS 5 can support.

[...] You cannot build a package on CentOS 6 for use on CentOS 5 without using a chroot of some sort.

[...]

answered Nov 18 '15 at 0:57
Etan Reisner




From curiosity, I'll take a look at querying rpm's information about rpm itself.


[root@kalkin ~]# rpm --query rpm

rpm-4.8.0-55.el6.x86_64

[root@kalkin ~]# rpm --query rpm --provides

config(rpm) = 4.8.0-55.el6
rpm = 4.8.0-55.el6
rpm(x86-64) = 4.8.0-55.el6

[root@kalkin ~]# rpm --query rpm --requires

/bin/bash
/bin/sh
/bin/sh
config(rpm) = 4.8.0-55.el6
coreutils
curl
db4-utils
libacl.so.1()(64bit)
libbz2.so.1()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libcap.so.2()(64bit)
libdb-4.7.so()(64bit)
libelf.so.1()(64bit)
liblua-5.1.so()(64bit)
liblzma.so.0()(64bit)
libm.so.6()(64bit)
libmagic.so.1()(64bit)
libnss3.so()(64bit)
libpopt.so.0()(64bit)
libpopt.so.0(LIBPOPT_0)(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
librpm.so.1()(64bit)
librpmbuild.so.1()(64bit)
librpmio.so.1()(64bit)
librt.so.1()(64bit)
libselinux.so.1()(64bit)
libz.so.1()(64bit)
popt >= 1.10.2.1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1



I note the presence of a shared library named "librpm" in the requirements: librpm.so.1()(64bit)
Perhaps this is part of the rpm-libs package.

I note also that this item appears as a requirement:
rtld(GNU_HASH)

and these items:
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

These dependencies and the existence of the rpm-4.8.0-55.el6.x86_64 package imply that rpm is used to upgrade itself.



Excerpt that sums up the rpmlib() items rather well:
www.spinics.net/lists/rpm/msg07663.html
Subject: Re: How to implement and check a rpm for an 'rpmlib' capability
From: Panu Matilainen <pmatilai@xxxxxxxxxxxxxxx>
Date: Sat, 02 Feb 2013 13:14:05 +0200

rpmlib() dependencies are provided by the running rpm instance, and cannot be provided by packages.





I have discovered from the book Maximum RPM that the rpm database can be used to check the validity of the filesystem state (or rather, the validity of the section of the filesystem state that is described by the packages in the rpm database). This can be done by using the --verify option and selecting all packages with the --all option.


Excerpts from:
ftp.rpm.org/max-rpm/ch-rpm-verify.html

Maximum RPM: Taking the RPM Package Manager to the Limit


Chapter 6. Using RPM to Verify Installed Packages

[...]


rpm -V - What Does it Do?

From time to time, it's necessary to make sure that everything on your system is "OK". Are you sure the packages you've installed are still configured properly? Have there been any changes made that you don't know about? Did you mistakenly start a recursive delete in
/usr
and now have to assess the damage?

RPM can help. It can alert you to changes made to any of the files installed by RPM. Also, if a package requires capabilities provided by another package, it can make sure the other package is installed, too.

The command
rpm -V
(The options
-y
and
--verify
are equivalent) verifies an installed package. Before we see how this is done, let's take a step back and look at the big picture.

Every time a package is installed, upgraded, or erased, the changes are logged in RPM's database. It's necessary for RPM to keep track of this information; otherwise it wouldn't be able to perform these operations correctly. You can think of the RPM database (and the disk space it consumes) as being the "price of admission" for the easy package management that RPM provides. [*]

[*]: Actually, the price is fairly low. For a completely RPM-based Linux distribution, it would be unusual to have a database over 5MB in size.

The RPM database reflects the configuration of the system on which it resides. When RPM accesses the database to see how files should be manipulated during an install, upgrade, or erase, it is using the database as a mirror of the system's configuration.

However, we can also use the system configuration as a mirror of the RPM database. What does this "backward" view give us? What purpose would be served?

The purpose would be to see if the system configuration accurately reflects the contents of the RPM database. If the system configuration doesn't match the database, then we can reach one of two conclusions:

1) The RPM database has become corrupt. The system configuration is unchanged.

2) The RPM database is intact. The system configuration has changed.

While it would be foolish to state that an RPM database has never become corrupt, it is a sufficiently rare occurrence that the second conclusion is much more likely. So RPM gives us a powerful verification tool, essentially for free.


What Does it Verify?

It would be handy if RPM did nothing more than verify that every file installed by a package actually exists on your system. In reality, RPM does much more. It makes sure that if a package depends on other packages to provide certain capabilities, the necessary packages are, in fact, installed. If the package builder created one, RPM will also run a special verification script that can verify aspects of the package's installation that RPM cannot.

Finally, every file installed by RPM is examined. No less than nine different attributes of each file can be checked. Here is the list of attributes:

- Owner
- Group
- Mode
- MD5 Checksum
- Size
- Major Number
- Minor Number
- Symbolic Link String
- Modification Time

Let's take a look at each of these attributes and why they are good things to check:

- File Ownership

Most operating systems today keep track of each file's creator. This is done primarily for resource accounting. Linux and UNIX also use file ownership to help determine access rights to the file. In addition, some files, when executed by a user, can temporarily change the user's ID, normally to a more privileged ID. Therefore, any change of file ownership may have far reaching effects on data security and system availability.

- File Group

In a similar manner to file ownership, a "group" specification is attached to each file. Primarily used for determining access rights, a file's group specification can also become a user's group ID, should that user execute the file's contents. Therefore, any changes in a file's group specification are important, and should be monitored.

- File Mode

Encompassing the file's "permissions", the mode is a set of bits that specifies permitted access for the file's owner, group members, and everyone else. Even more important are two additional bits that determine whether a user's group or user ID should be changed if they execute the program contained in the file. Since these little bombshells can let any user become root for the duration of the program, it pays to be extra careful with a file's permissions.

- MD5 Checksum

The MD5 checksum of a file is simply a 128-bit number that is mathematically derived from the contents of the file. The MD5 algorithm was designed by Ron Rivest, the "R" in the popular RSA public-key encryption algorithm. The "MD" in "MD5" stands for Message Digest, which is a pretty accurate description of what it does.

Unlike literary digests, an MD5 checksum conveys no information about the contents of the original file. However, it possesses one unique trait:

Any change to the file, no matter how small, results in a change to the MD5 checksum. [*]


RPM creates MD5 checksums of all files it manipulates, and stores them in its database. For all intents and purposes, if one of these files is changed, the MD5 checksum will change, and RPM will detect it.

[*]: From a strictly theoretical standpoint, this is not entirely true. Using the lingo of cryptologists, it is believed to be "computationally infeasible" to find two messages that produce the same MD5 checksum.

- File Size

As if the use of MD5 isn't enough, RPM also keeps track of file sizes. A difference of even one byte more or less will not go unnoticed.

- Major Number

Device character and block files possess a major number. The major number is used to communicate information to the device driver associated with the special file. For instance, under Linux the special files for SCSI disk drives should have a major number of 8, while the major number for an IDE disk drive's special file would be 3. As you can imagine, any change to a file's major number can have disastrous effects, and is tracked by RPM.

- Minor Number

A file's minor number is similar in concept to the major number, but conveys different information to the device driver. In the case of disk drives, this information can consist of a unit identifier. Should the minor number change, RPM will detect it.

- Symbolic Link

If the file in question is really a symbolic link, the text string containing the name of the linked-to file is checked.

- Modification Time

Most operating systems keep track of the date and time that a file was last modified. RPM uses this to its advantage by keeping modification times in its database.



Key points:
- Every time a package is installed, upgraded, or erased, the changes are logged in RPM's database.
- The RPM database reflects the configuration of the system on which it resides.
- When RPM accesses the database to see how files should be manipulated during an install, upgrade, or erase, it is using the database as a mirror of the system's configuration.
- We can also use the system configuration as a mirror of the RPM database.
- We can see if the system configuration accurately reflects the contents of the RPM database.

I think these observations apply to any situation where:
- a system exists
- an attempt is made to track its state using an information system

Examples: Inventory management, bookkeeping.




Excerpts from:
ftp.rpm.org/max-rpm/s1-rpm-verify-what-to-verify.html

Maximum RPM: Taking the RPM Package Manager to the Limit


Chapter 6. Using RPM to Verify Installed Packages


Selecting What to Verify, and How

[...]


The Package Label - Verify an Installed Package Against the RPM Database

You can simply follow the
rpm -V
command with all or part of a package label. As with every other RPM command that accepts package labels, you'll need to carefully specify each part of the label you include. Keep in mind that package names are case-sensitive, so
rpm -V PackageName
and
rpm -V packagename
are not the same. Let's verify the
initscripts
package:

# rpm -V initscripts
#


While it looks like RPM didn't do anything, the following steps were performed:

- For every file in the package, RPM checked the nine file attributes that were discussed above.

- If the package was built with dependencies, the RPM database was searched to ensure the packages that satisfy those dependencies were installed.

- If the package was built with a verification script, that script was executed.

In our example, each of these steps was performed without error - the package verified successfully. Remember, with
rpm -V
you'll only see output if a package fails to verify.


-a - Verify All Installed Packages Against the RPM Database

If you add
-a
to
rpm -V
, you can easily verify every installed package on your system. It might take a while, but when it's done, you'll know exactly what's been changed on your system:

# rpm -Va .M5....T /usr/X11R6/lib/X11/fonts/misc/fonts.dir missing /var/spool/at/.lockfile missing /var/spool/at/spool S.5....T /usr/lib/rhs/glint/icon.pyc ..5....T c /etc/inittab ..5..... /usr/bin/loadkeys #


Don't be too surprised if
rpm -Va
turns up a surprising number of files that failed verification. RPM's verification process is very strict! In many cases, the changes flagged don't indicate problems - they are only an indication of your system's configuration being different than what the builders of the installed packages had on their system. Also, some attributes change during normal system operation. However, it would be wise to check into each verification failure, just to make sure.




Switch to Kalkin.


[root@kalkin work]# rpm --verify --all

S.5....T. c /etc/yum.repos.d/CentOS-Base.repo .......T. c /etc/inittab ....L.... c /etc/pam.d/fingerprint-auth ....L.... c /etc/pam.d/password-auth ....L.... c /etc/pam.d/smartcard-auth ....L.... c /etc/pam.d/system-auth



Earlier, I edited /etc/yum.repos.d/CentOS-Base.repo.

Hm.



Excerpt from:
ftp.rpm.org/max-rpm/s1-rpm-verify-output.html

Maximum RPM: Taking the RPM Package Manager to the Limit


Chapter 6. Using RPM to Verify Installed Packages


When Verification Fails - rpm -V Output

When verifying a package, RPM produces output only if there is a verification failure. When a file fails verification, the format of the output is a bit cryptic, but it packs all the information you need into one line per file. Here is the format:

SM5DLUGT c [file]


Where:

-
S
is the file size.

-
M
is the file's mode.

-
5
is the MD5 checksum of the file.

-
D
is the file's major and minor numbers.

-
L
is the file's symbolic link contents.

-
U
is owner of the file.

-
G
is the file's group.

-
T
is the modification time of the file.

-
c
appears only if the file is a configuration file. This is handy for quickly identifying config files, as they are very likely to change, and therefore, very unlikely to verify successfully.

-
[file]
is the file that failed verification. The complete path is listed to make it easy to find.

It's unlikely that every file attribute will fail to verify, so each of the eight attribute flags will only appear if there is a problem. Otherwise, a "." will be printed in that flag's place. Let's look at an example or two:

.M5....T /usr/X11R6/lib/X11/fonts/misc/fonts.dir


In this case, the mode, MD5 checksum, and modification time for the specified file have failed to verify. The file is not a config file (Note the absence of a "c" between the attribute list and the filename).

S.5....T c /etc/passwd


Here, the size, checksum, and modification time of the system password file have all changed. The "c" indicates that this is a config file.

missing /var/spool/at/spool


This last example illustrates what RPM does when a file, that should be there, is missing entirely.



Let's look at the output again.

[root@kalkin work]# rpm --verify --all

S.5....T. c /etc/yum.repos.d/CentOS-Base.repo .......T. c /etc/inittab ....L.... c /etc/pam.d/fingerprint-auth ....L.... c /etc/pam.d/password-auth ....L.... c /etc/pam.d/smartcard-auth ....L.... c /etc/pam.d/system-auth



So, they're all config files. These are the files that are most likely to change.

When I edited /etc/yum.repos.d/CentOS-Base.repo, I changed the file's size, its MD5 checksum, and its modification time.

The modification time of /etc/inittab has changed.

Each of the following files contains a symbolic link, which has changed:
- /etc/pam.d/fingerprint-auth
- /etc/pam.d/password-auth
- /etc/pam.d/smartcard-auth
- /etc/pam.d/system-auth


[root@kalkin work]# file /etc/pam.d/fingerprint-auth

/etc/pam.d/fingerprint-auth: symbolic link to `fingerprint-auth-ac'



Ok. I'll leave these alone. A few config files changing is apparently to be expected. rpm thinks that everything else in the packages is in order.



I'd like to get an --info and --dump of every package, as a snapshot of the state of the section of Kalkin's filesystem managed by rpm.

[root@kalkin work]# mkdir results


[root@kalkin work]# rpm --query --all | while read line ; do rpm --query --info $line > results/$line.info; done


[root@kalkin work]# rpm --query --all | while read line ; do rpm --query --dump $line > results/$line.dump; done


[root@kalkin work]# du -h

5.6M ./results 11M ./rpms 4.2M ./archived 20M


[root@kalkin work]# mv results 20180329_kalkin_rpm_package_info_and_dumps


[root@kalkin work]# tar -zcf 20180329_kalkin_rpm_package_info_and_dumps.tar.gz 20180329_kalkin_rpm_package_info_and_dumps


[root@kalkin work]# du -h 20180329_kalkin_rpm_package_info_and_dumps.tar.gz

854K 20180329_kalkin_rpm_package_info_and_dumps.tar.gz



Transfer 20180329_kalkin_rpm_package_info_and_dumps.tar.gz to Aineko and add it as an asset to this article.



Note that the compression of 20180329_kalkin_rpm_package_info_and_dumps reduced it from 5.6 MB to 854 KB.




Let's see what happens when I tell rpm to check the digital signature of the gcc package, without having first imported the key that signed it.



[root@kalkin work]# rpm --checksig rpms/gcc-4.4.7-18.el6.x86_64.rpm

rpms/gcc-4.4.7-18.el6.x86_64.rpm: RSA sha1 ((MD5) PGP) md5 NOT OK (MISSING KEYS: (MD5) PGP#c105b9de)




Next, I'll tell rpm to import the Centos 6 signing key.



If I tell rpm to import a key into the rpm database, will rpm in turn cause gpg to import the key into the gpg keyring database?


[root@kalkin work]# gpg --list-keys


[root@kalkin work]# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6


[root@kalkin work]# gpg --list-keys


[root@kalkin work]# rpm -qa gpg-pubkey*

gpg-pubkey-c105b9de-4e0fd3a3



Apparently not.




Excerpt from Maximum RPM:
ftp.rpm.org/max-rpm/s1-rpm-install-additional-options.html

In order for RPM to do its handiwork, it needs access to an RPM database. Normally, this database exists in the directory specified by the
rpmrc
file entry,
dbpath
. By default,
dbpath
is set to
/var/lib/rpm
.




[root@kalkin work]# ls -1 /var/lib/rpm

Basenames
Conflictname
__db.001
__db.002
__db.003
__db.004
Dirnames
Filedigests
Group
Installtid
Obsoletename
Packages
Providename
Provideversion
Pubkeys
Requirename
Requireversion
Sha1header
Sigmd5
Triggername

[root@kalkin work]# file /var/lib/rpm/Pubkeys

/var/lib/rpm/Pubkeys: Berkeley DB (Hash, version 9, native byte-order)



Hm. I think that rpm stores imported public keys in the /var/lib/rpm/Pubkeys file.

I think rpm may create a separate gpg keyring (i.e. not the gpg one in the home directory
/root
) or a temporary gpg keyring in order to use gpg to check a package's digital signature.




[root@kalkin work]# rpm --checksig rpms/gcc-4.4.7-18.el6.x86_64.rpm

rpms/gcc-4.4.7-18.el6.x86_64.rpm: rsa sha1 (md5) pgp md5 OK

[root@kalkin work]# rpm --checksig rpms/gcc-4.4.7-18.el6.x86_64.rpm --verbose

rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: OK Header SHA1 digest: OK (799acabb020fbb56565dbd8dd34522ad9e302014) V3 RSA/SHA1 Signature, key ID c105b9de: OK MD5 digest: OK (bca07113216ae1724795bd39bff6daa1)



Note: Using the --verbose option shows the key ID of the signing key.

Hm. It looks to me as though the header and the package are signed separately. The two lines starting with "Header" presumably relate to the header rather than the package. For both the header and the package, the hash/digest and the signature are checked and found to be valid. Both signatures were created by the key with the key ID c105b9de.



Excerpt from Maximum RPM:
ftp.rpm.org/max-rpm/s1-rpm-checksig-using-rpm-k.html

People versed in octal numbers will note that only one bit has been changed in the entire file. That's the smallest possible change you can make! Let's see how our bogus friend fares:

# rpm -K rpm-2.3-1.i386-bogus.rpm
rpm-2.3-1.i386-bogus.rpm: size PGP MD5 NOT OK
#


Given that the command's output ends with
NOT OK
in big capital letters, it's obvious there's a problem. Since the word
size
was printed in lowercase, the bogus package's size was OK, which makes sense - we only changed the value of one bit without adding or subtracting anything else.




So in this earlier result:

[root@kalkin work]# rpm --checksig rpms/gcc-4.4.7-18.el6.x86_64.rpm

rpms/gcc-4.4.7-18.el6.x86_64.rpm: RSA sha1 ((MD5) PGP) md5 NOT OK (MISSING KEYS: (MD5) PGP#c105b9de)


The sha1 and md5 digests were checked and found to be valid ("sha1" and "md5" were in lower case).





Next: Use the --test option to see how the installation would hypothetically proceed.

--test = Do not install the package, simply check for and report potential conflicts.


[root@kalkin work]# rpm --test rpms/gcc-4.4.7-18.el6.x86_64.rpm

[some information about rpm and the --usage message is printed]

[root@kalkin work]# rpm --install --test rpms/gcc-4.4.7-18.el6.x86_64.rpm

error: Failed dependencies: cloog-ppl >= 0.15 is needed by gcc-4.4.7-18.el6.x86_64.rpm cpp = 4.4.7-18.el6 is needed by gcc-4.4.7-18.el6.x86_64.rpm glibc-devel >= 2.2.90-12 is needed by gcc-4.4.7-18.el6.x86_64.rpm libgomp = 4.4.7-18.el6 is needed by gcc-4.4.7-18.el6.x86_64.rpm libgomp.so.1()(64bit) is needed by gcc-4.4.7-18.el6.x86_64.rpm




So, here is the list of missing dependencies:
- cloog-ppl >= 0.15
- cpp = 4.4.7-18.el6
- glibc-devel >= 2.2.90-12
- libgomp = 4.4.7-18.el6
- libgomp.so.1()(64bit)



These match my conclusions earlier, when I was investigating the --whatprovides option.

These packages are not installed:
cloog-ppl >= 0.15
cpp = 4.4.7-18.el6
glibc-devel >= 2.2.90-12
libgomp = 4.4.7-18.el6

These shared libraries are not installed:
libgomp.so.1()(64bit) [probably provided by package libgomp = 4.4.7-18.el6]

These items are not present:
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rpmlib(PayloadIsXz) <= 5.2-1
-> I don't think these are shared libraries. They look like another type of item.


These rpmlib dependencies:
- rpmlib(CompressedFileNames) <= 3.0.4-1
- rpmlib(FileDigests) <= 4.6.0-1
- rpmlib(PartialHardlinkSets) <= 4.0.4-1
- rpmlib(PayloadFilesHavePrefix) <= 4.0-1
- rpmlib(VersionedDependencies) <= 3.0.3-1
- rpmlib(PayloadIsXz) <= 5.2-1
didn't cause any problems when I ran
rpm --install --test [package_path]
.

I had thought that perhaps this one:
- rpmlib(PayloadIsXz) <= 5.2-1
might cause trouble, since its version number (5.2-1) is greater than the version of number of rpm on Kalkin (4.8.0).




I'll copy the earlier output of
rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --requires

here:

[root@kalkin work]# rpm --query --package rpms/gcc-4.4.7-18.el6.x86_64.rpm --requires

warning: rpms/gcc-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
/bin/sh
/bin/sh
/bin/sh
/sbin/install-info
/sbin/install-info
binutils >= 2.19.51.0.14-33
cloog-ppl >= 0.15
cpp = 4.4.7-18.el6
glibc-devel >= 2.2.90-12
libc.so.6()(64bit)
libc.so.6(GLIBC_2.11)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libgcc >= 4.4.7-18.el6
libgcc_s.so.1()(64bit)
libgomp = 4.4.7-18.el6
libgomp.so.1()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1







Much earlier, I looked up likely dependencies for gcc from various sources.

Let's list them here:

Items:
- GMP library
- MPFR library
- MPC library
- gcc-c++
- libgcc
- libstdc++
- glibc

I'm including here only the x86_64 packages.

Basic packages (Centos mirror):
- gcc-4.4.7-18.el6.x86_64.rpm
- glibc-2.12-1.209.el6.x86_64.rpm
- gmp-4.3.1-12.el6.x86_64.rpm
- libstdc++-4.4.7-18.el6.x86_64.rpm
- mpfr-2.4.1-6.el6.x86_64.rpm

Basic packages (EPEL mirror):
- libmpc-devel-0.8-3.el6.x86_64.rpm

More packages (Centos mirror):
- gcc-c++-4.4.7-18.el6.x86_64.rpm
- glibc-common-2.12-1.209.el6.x86_64.rpm
- glibc-devel-2.12-1.209.el6.x86_64.rpm
- glibc-headers-2.12-1.209.el6.x86_64.rpm
- glibc-static-2.12-1.209.el6.x86_64.rpm
- glibc-utils-2.12-1.209.el6.x86_64.rpm
- gmp-devel-4.3.1-12.el6.x86_64.rpm
- gmp-static-4.3.1-12.el6.x86_64.rpm
- libgcc-4.4.7-18.el6.x86_64.rpm
- libstdc++-devel-4.4.7-18.el6.x86_64.rpm
- libstdc++-docs-4.4.7-18.el6.x86_64.rpm
- mpfr-devel-2.4.1-6.el6.x86_64.rpm



Thoughts:
- I see no mention of cloog-ppl.
- libgomp may be a name for the GMP library item.
-- actually, the GMP package is probably this package from the "all packages" list: gmp-4.3.1-12.el6.x86_64
- cpp may be a name for the gcc-c++ item.
- glibc-devel is a dependency, rather than glibc.
- The MPFR and MPC libraries do not appear in the requirements list.


What is the difference between glibc-devel and glibc?



Excerpt from:
stackoverflow.com/questions/2358801/what-are-devel-packages


Q:

What are *-devel packages?

What is the utility of devel packages like "libgtk+-devel" or "python-devel" etc.? Do they contain source of the library? How is it different from non-devel packages like libgtk+?

edited Mar 2 '10 at 4:29
Pascal Cuoq

asked Mar 1 '10 at 20:22
Variance


A:

The
*-devel
packages (usually called
*-dev
in Debian-based distributions) are usually all the files necessary to compile code against a given library.

For running an application using the library
libfoo
only the actualy shared library file (
*.so.*
, for example
libfoo.so.1.0
) are needed (plus possibly some data files and some version-specific symlinks).

When you actually want to compile a C application that uses that library you'll need the header files (
*.h
, for example
foo.h
) that describe the interface of that application as well as a version-less symlink to the shared library (
*.so
, for example
libfoo.so
->
libfoo.so.1.0
). Those are usually bundled in the
*-devel
packages.

Sometimes the
*-devel
packages also include statically compiled versions of the libraries (
*.a
, for example
libfoo.a
) in case you want to build a complete stand-alone application that doesn't depend on dynamic libraries at all.

Other languages (such as Java, Python, ...) use a different way of noting the API of a library (effectively including all the necessary information in the actual library) and thus usually need no separate
*-devel
packages (except maybe for documentation and additional tools).

edited Mar 2 '10 at 7:03
answered Mar 1 '10 at 20:26
Joachim Sauer


A:

They usually contain necessary headers and libraries. For example, python-devel will provide the Python headers and libraries that you need if you want to embed the Python interpreter in your own application. Some additional tools and documentation are included, too (e.g. a developer manual or code examples).

answered Mar 1 '10 at 20:24
AndiDog


Comment:

It's not worth opening another answer, but in addition to existing answers, I should emphasize that packagers try to put in a non-devel package such as
libgtk+
the minimum footprint necessary to run (as opposed to "develop") gtk+ programs. That means only dynamic libraries and configuration files. Everything else goes in the complementary
-devel
package.

- Pascal Cuoq Mar 2 '10 at 4:33




Notes:
- In Answer 1, "that describe the interface of that application" should probably be "that describe the interface of that package".


So:

- Normal packages contain the compiled code and the items necessary for running it.
-- The shared library file (always dynamic?) plus possibly some data/configuration files and some version-specific symlinks.
-- Some languages (such as Java, Python, ...) use a different way of noting the API of a library (effectively including all the necessary information in the actual library) and thus packages containing code written only in these languages usually need no separate development packages (except maybe for documentation and additional tools).

- Development packages (with the suffix "-devel" or "-dev") usually contain all the files necessary to compile code against a given library (i.e. "develop" against it).
-- They contain the headers and libraries that are necessary for embedding the package (or just parts of it?) into a new application that you wish to compile.
-- The header files describe the interface of the package.
-- There will also be a version-less symlink to the shared library.
-- There may also be statically compiled versions of the libraries (
*.a
, for example
libfoo.a
) in case you want to build a complete stand-alone application that doesn't depend on dynamic libraries at all.
-- There may also be additional tools and documentation (e.g. a developer manual or code examples).

- Dynamic shared library filenames have the format
*.so.*
, e.g.
libfoo.so.1.0
.
- Statically compiled library filenames have the format
*.a
, e.g.
libfoo.a
.
- Header filenames have the format
*.h
, e.g.
foo.h
.
- Version-less symlink filename format:
*.so
.
-- Example:
libfoo.so
->
libfoo.so.1.0
.










Let's research the missing dependencies:
- cloog-ppl >= 0.15
- cpp = 4.4.7-18.el6
- glibc-devel >= 2.2.90-12
- libgomp = 4.4.7-18.el6
- libgomp.so.1()(64bit)


I think that the package libgomp will probably supply the shared library file libgomp.so.1()(64bit).


Search on:
pkgs.org

1) for "cloog-ppl"
[among other choices]
cloog-ppl-0.15.7-1.2.el6.x86_64.rpm

2) for "cpp"
[among other choices]
cpp-7.1.1-3.fc26.x86_64.rpm
In Alternatives section, there is a link to "cpp" [All Repositories].
Following it, and choosing Centos 6, leads to [among other choices]:
cpp-4.4.7-18.el6.x86_64.rpm

Before searching further, specify Distribution = Centos 6.

3) for "glibc-devel"
[among other choices]
glibc-devel-2.12-1.209.el6.x86_64.rpm

4) for "libgomp"
[among other choices]
libgomp-4.4.7-18.el6.x86_64.rpm

Note: In the Provides section for libgomp-4.4.7-18.el6.x86_64.rpm, the shared library libgomp.so.1()(64bit) is listed.

Links to each of these packages on pkgs.org:
centos.pkgs.org/6/centos-x86_64/cloog-ppl-0.15.7-1.2.el6.x86_64.rpm.html
centos.pkgs.org/6/centos-x86_64/cpp-4.4.7-18.el6.x86_64.rpm.html
centos.pkgs.org/6/centos-x86_64/glibc-devel-2.12-1.209.el6.x86_64.rpm.html
centos.pkgs.org/6/centos-x86_64/libgomp-4.4.7-18.el6.x86_64.rpm.html






Details on pkgs.org for each of these packages:




1) cloog-ppl-0.15.7-1.2.el6.x86_64.rpm

Description:

cloog-ppl - Parma Polyhedra Library backend (ppl) based version of the Cloog binaries

- Distribution: CentOS 6
- Repository: CentOS x86_64
- Package name: cloog-ppl
- Package version: 0.15.7
- Package release: 1.2.el6
- Package architecture: x86_64
- Package type: rpm
- Installed size: 181.04 KB
- Download size: 93.02 KB
- Official Mirror: mirror.centos.org

The dynamic shared libraries of the Chunky Loop Generator

Requires:
- /sbin/ldconfig
- libc.so.6(GLIBC_2.7)(64bit)
- libgmp.so.3()(64bit)
- libgmpxx.so.4()(64bit)
- libppl.so.7()(64bit)
- libppl_c.so.2()(64bit)
- rtld(GNU_HASH)

Provides:
- cloog-ppl = 0.15.7-1.2.el6
- cloog-ppl(x86-64) = 0.15.7-1.2.el6
- libcloog.so.0()(64bit)

Download:
- Binary package: cloog-ppl-0.15.7-1.2.el6.x86_64.rpm
- Source package: cloog-0.15.7-1.2.el6.src.rpm

Files:
- /usr/bin/cloog
- /usr/lib64/libcloog.so.0
- /usr/lib64/libcloog.so.0.0.0
- /usr/share/doc/cloog-ppl-0.15.7/LICENSE
- /usr/share/doc/cloog-ppl-0.15.7/README
- /usr/share/info/cloog.info.gz




2) cpp-4.4.7-18.el6.x86_64.rpm

Description:

cpp - The C Preprocessor

- Distribution: CentOS 6
- Repository: CentOS x86_64
- Package name: cpp
- Package version: 4.4.7
- Package release: 18.el6
- Package architecture: x86_64
- Package type: rpm
- Installed size: 9.54 MB
- Download size: 3.74 MB
- Official Mirror: mirror.centos.org

Cpp is the GNU C-Compatible Compiler Preprocessor.

Cpp is a macro processor which is used automatically by the C compiler to transform your program before actual compilation. It is called a macro processor because it allows you to define macros, abbreviations for longer constructs.

The C preprocessor provides four separate functionalities: the inclusion of header files (files of declarations that can be substituted into your program); macro expansion (you can define macros, and the C preprocessor will replace the macros with their definitions throughout the program); conditional compilation (using special preprocessing directives, you can include or exclude parts of the program according to various conditions); and line control (if you use a program to combine or rearrange source files into an intermediate file which is then compiled, you can use line control to inform the compiler about where each source line originated).

You should install this package if you are a C programmer and you use macros.

Requires:
- /sbin/install-info
- libc.so.6(GLIBC_2.7)(64bit)
- libdl.so.2()(64bit)
- libdl.so.2(GLIBC_2.2.5)(64bit)
- libgmp.so.3()(64bit)
- libmpfr.so.1()(64bit)
- rtld(GNU_HASH)

Provides:
- cpp = 4.4.7-18.el6
- cpp = 4.4.4-15.el6
- cpp(x86-64) = 4.4.7-18.el6

Download:
- Binary package: cpp-4.4.7-18.el6.x86_64.rpm
- Source package: gcc-4.4.7-18.el6.src.rpm

Files:
- /lib/cpp
- /usr/bin/cpp
- /usr/libexec/gcc/
- /usr/libexec/gcc/x86_64-redhat-linux/4.4.7
- /usr/libexec/gcc/x86_64-redhat-linux/4.4.4/cc1
- /usr/share/info/cpp.info.gz
- /usr/share/info/cppinternals.info.gz
- /usr/share/locale/be/LC_MESSAGES/cpplib.mo
- /usr/share/locale/ca/LC_MESSAGES/cpplib.mo
- /usr/share/locale/da/LC_MESSAGES/cpplib.mo
- /usr/share/locale/de/LC_MESSAGES/cpplib.mo
- /usr/share/locale/el/LC_MESSAGES/cpplib.mo
- /usr/share/locale/es/LC_MESSAGES/cpplib.mo
- /usr/share/locale/fr/LC_MESSAGES/cpplib.mo
- /usr/share/locale/id/LC_MESSAGES/cpplib.mo
- /usr/share/locale/ja/LC_MESSAGES/cpplib.mo
- /usr/share/locale/nl/LC_MESSAGES/cpplib.mo
- /usr/share/locale/sv/LC_MESSAGES/cpplib.mo
- /usr/share/locale/tr/LC_MESSAGES/cpplib.mo
- /usr/share/locale/uk/LC_MESSAGES/cpplib.mo
- /usr/share/locale/vi/LC_MESSAGES/cpplib.mo
- /usr/share/locale/zh_CN/LC_MESSAGES/cpplib.mo
- /usr/share/locale/zh_TW/LC_MESSAGES/cpplib.mo
- /usr/share/man/man1/cpp.1.gz




3) glibc-devel-2.12-1.209.el6.x86_64.rpm

Description:

glibc-devel - Object files for development using standard C libraries

- Distribution: CentOS 6
- Repository: CentOS x86_64
- Package name: glibc-devel
- Package version: 2.12
- Package release: 1.209.el6
- Package architecture: x86_64
- Package type: rpm
- Installed size: 967.16 KB
- Download size: 990.43 KB
- Official Mirror: mirror.centos.org

The glibc-devel package contains the object files necessary for developing programs which use the standard C libraries (which are used by nearly all programs). If you are developing programs which will use the standard C libraries, your system needs to have these standard object files available in order to create the executables.

Install glibc-devel if you are going to develop programs which will use the standard C libraries.

Requires:
- /sbin/install-info
- glibc = 2.12-1.209.el6
- glibc-headers = 2.12-1.209.el6
- glibc-headers
- libBrokenLocale.so.1()(64bit)
- libanl.so.1()(64bit)
- libcidn.so.1()(64bit)
- libcrypt.so.1()(64bit)
- libdl.so.2()(64bit)
- libm.so.6()(64bit)
- libnsl.so.1()(64bit)
- libnss_compat.so.2()(64bit)
- libnss_dns.so.2()(64bit)
- libnss_files.so.2()(64bit)
- libnss_hesiod.so.2()(64bit)
- libnss_nis.so.2()(64bit)
- libnss_nisplus.so.2()(64bit)
- libresolv.so.2()(64bit)
- librt.so.1()(64bit)
- libthread_db.so.1()(64bit)
- libutil.so.1()(64bit)

Provides:
- glibc-devel = 2.12-1.209.el6
- glibc-devel(x86-64) = 2.12-1.209.el6

Download:
- Binary package: glibc-devel-2.12-1.209.el6.x86_64.rpm
- Source package: glibc-2.12-1.209.el6.src.rpm

Files
- /usr/include/gnu/stubs-64.h
- /usr/lib64/Mcrt1.o
- /usr/lib64/Scrt1.o
- /usr/lib64/crt1.o
- /usr/lib64/crti.o
- /usr/lib64/crtn.o
- /usr/lib64/gcrt1.o
- /usr/lib64/libBrokenLocale.so
- /usr/lib64/libanl.so
- /usr/lib64/libbsd-compat.a
- /usr/lib64/libbsd.a
- /usr/lib64/libc.so
- /usr/lib64/libc_nonshared.a
- /usr/lib64/libcidn.so
- /usr/lib64/libcrypt.so
- /usr/lib64/libdl.so
- /usr/lib64/libg.a
- /usr/lib64/libieee.a
- /usr/lib64/libm.so
- /usr/lib64/libmcheck.a
- /usr/lib64/libnsl.so
- /usr/lib64/libnss_compat.so
- /usr/lib64/libnss_dns.so
- /usr/lib64/libnss_files.so
- /usr/lib64/libnss_hesiod.so
- /usr/lib64/libnss_nis.so
- /usr/lib64/libnss_nisplus.so
- /usr/lib64/libpthread.so
- /usr/lib64/libpthread_nonshared.a
- /usr/lib64/libresolv.so
- /usr/lib64/librpcsvc.a
- /usr/lib64/librt.so
- /usr/lib64/libthread_db.so
- /usr/lib64/libutil.so
- /usr/share/info/libc.info-1.gz
- /usr/share/info/libc.info-10.gz
- /usr/share/info/libc.info-11.gz
- /usr/share/info/libc.info-2.gz
- /usr/share/info/libc.info-3.gz
- /usr/share/info/libc.info-4.gz
- /usr/share/info/libc.info-5.gz
- /usr/share/info/libc.info-6.gz
- /usr/share/info/libc.info-7.gz
- /usr/share/info/libc.info-8.gz
- /usr/share/info/libc.info-9.gz
- /usr/share/info/libc.info.gz




4) libgomp-4.4.7-18.el6.x86_64.rpm

Description:

libgomp - GCC OpenMP v3.0 shared support library

- Distribution: CentOS 6
- Repository: CentOS x86_64
- Package name: libgomp
- Package version: 4.4.7
- Package release: 18.el6
- Package architecture: x86_64
- Package type: rpm
- Installed size: 124.98 KB
- Download size: 134.27 KB
- Official Mirror: mirror.centos.org

This package contains GCC shared support library which is needed for OpenMP v3.0 support.

Requires:
- /sbin/install-info
- /sbin/ldconfig
- libc.so.6(GLIBC_2.6)(64bit)
- libpthread.so.0()(64bit)
- libpthread.so.0(GLIBC_2.2.5)(64bit)
- libpthread.so.0(GLIBC_2.3.4)(64bit)
- librt.so.1()(64bit)
- librt.so.1(GLIBC_2.2.5)(64bit)
- rtld(GNU_HASH)

Provides:
- libgomp = 4.4.7-18.el6
- libgomp = 4.4.4-15.el6
- libgomp(x86-64) = 4.4.7-18.el6
- libgomp.so.1()(64bit)
- libgomp.so.1(GOMP_1.0)(64bit)
- libgomp.so.1(GOMP_2.0)(64bit)
- libgomp.so.1(GOMP_3.0)(64bit)
- libgomp.so.1(GOMP_4.0)(64bit)
- libgomp.so.1(OMP_1.0)(64bit)
- libgomp.so.1(OMP_2.0)(64bit)
- libgomp.so.1(OMP_3.0)(64bit)
- libgomp.so.1(OMP_3.1)(64bit)
- libgomp.so.1(OMP_4.0)(64bit)

Download:
- Binary package: libgomp-4.4.7-18.el6.x86_64.rpm
- Source package: gcc-4.4.7-18.el6.src.rpm

Files:
- /usr/lib64/libgomp.so.1
- /usr/lib64/libgomp.so.1.0.0
- /usr/share/doc/libgomp-4.4.7/ChangeLog.bz2
- /usr/share/info/libgomp.info.gz



On Aineko, click the linked binary package file in the Download section of each package page on pkgs.org.






Earlier, I saved the result of running
rpm --query --dump [package_name]
and
rpm --query --info [package_name]
for each package.

It would be useful to also have the lists of the dependencies that each package provides.

Let's extract and archive the dependencies provided by each package included in Centos 6.9 Minimal.


[root@kalkin work]# mkdir results


[root@kalkin work]# rpm --query --all | while read line ; do rpm --query $line --provides > results/$line.provides ; done


[root@kalkin work]# du -h

1.3M ./results 11M ./rpms 4.2M ./archived 5.6M ./tmp/20180329_kalkin_rpm_package_info_and_dumps 6.5 ./tmp 22M


[root@kalkin work]# mv results 20180401_rpm_package_provides


[root@kalkin work]# tar -zcf 20180401_rpm_package_provides.tar.gz 20180401_rpm_package_provides


[root@kalkin work]# du -h 20180401_rpm_package_provides.tar.gz

168K 20180401_rpm_package_provides.tar.gz




Transfer 20180401_rpm_package_provides.tar.gz to Aineko and add it as an asset to this article.
- Later update: For consistency, I should have named it
20180401_kalkin_rpm_package_provides.tar.gz.



Note that the compression of 20180401_rpm_package_provides reduced it from 1.3 MB to 168 KB.




Transfer all the binary rpm package files to Kalkin.

Package list:
- cloog-ppl-0.15.7-1.2.el6.x86_64.rpm
- cpp-4.4.7-18.el6.x86_64.rpm
- glibc-devel-2.12-1.209.el6.x86_64.rpm
- libgomp-4.4.7-18.el6.x86_64.rpm

libgomp-4.4.7-18.el6.x86_64.rpm provides libgomp.so.1()(64bit).


Missing dependencies reported earlier when --test installing gcc rpm:
- cloog-ppl >= 0.15
- cpp = 4.4.7-18.el6
- glibc-devel >= 2.2.90-12
- libgomp = 4.4.7-18.el6
- libgomp.so.1()(64bit)





Next: Check the signature of each new rpm package.

[root@kalkin work]# rpm --checksig rpms/cloog-ppl-0.15.7-1.2.el6.x86_64.rpm --verbose

rpms/cloog-ppl-0.15.7-1.2.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID c105b9de: OK Header SHA1 digest: OK (2dc9d8923aca5c9e4aff5396c8217a7309ccf1cd) V3 RSA/SHA256 Signature, key ID c105b9de: OK MD5 digest: OK (45bf8b3d5ecdf00b8920cae8215cd23f)


[root@kalkin work]# rpm --checksig rpms/cpp-4.4.7-18.el6.x86_64.rpm --verbose

rpms/cpp-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: OK Header SHA1 digest: OK (a49718529caa69c33a5dfa17865dc8d460fd7b41) V3 RSA/SHA1 Signature, key ID c105b9de: OK MD5 digest: OK (4b99c846bb3ad92362746fec822988b8)


[root@kalkin work]# rpm --checksig rpms/glibc-devel-2.12-1.209.el6.x86_64.rpm --verbose

rpms/glibc-devel-2.12-1.209.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: OK Header SHA1 digest: OK (2997a9167354a03d2a1146fa1a638ce4448d8b02) V3 RSA/SHA1 Signature, key ID c105b9de: OK MD5 digest: OK (aa4e6e73c0cfb605384af27d9e056b13)


[root@kalkin work]# rpm --checksig rpms/libgomp-4.4.7-18.el6.x86_64.rpm --verbose

rpms/libgomp-4.4.7-18.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: OK Header SHA1 digest: OK (c809f91a3d7f0159cbde72a3b2b1b157437593e5) V3 RSA/SHA1 Signature, key ID c105b9de: OK MD5 digest: OK (1160c13988916ec362c1c9f30d16288f)



Notes:
- All signatures are valid.
- Both signatures in all four packages have key ID == c105b9de (i.e. the Centos 6 signing key's key ID).
- The signatures for the cloog-ppl package are RSA/SHA256 instead of RSA/SHA1.



Next: Run a --test install for each package. Note which dependencies, if any, are lacking for each of them on the system.



[root@kalkin work]# rpm --install rpms/cloog-ppl-0.15.7-1.2.el6.x86_64.rpm --test

error: Failed dependencies: libppl.so.7()(64bit) is needed by cloog-ppl-0.15.7-1.2.el6.x86_64 libppl_c.so.2()(64bit) is needed by cloog-ppl-0.15.7-1.2.el6.x86_64


[root@kalkin work]# rpm --install rpms/cpp-4.4.7-18.el6.x86_64.rpm --test

error: Failed dependencies: libmpfr.so.1()(64bit) is needed by cpp-4.4.7-18.el6.x86_64


[root@kalkin work]# rpm --install rpms/glibc-devel-2.12-1.209.el6.x86_64.rpm --test

error: Failed dependencies: glibc-headers is needed by glibc-devel-2.12-1.209.el6.x86_64 glibc-headers = 2.12-1.209.el6 is needed by glibc-devel-2.12-1.209.el6.x86_64


[root@kalkin work]# rpm --install rpms/libgomp-4.4.7-18.el6.x86_64.rpm --test



Note: The above output is error output. To redirect this output successfully to
| tee -a work.log
, add
2>&1
.
Example:
# rpm --install rpms/cloog-ppl-0.15.7-1.2.el6.x86_64.rpm --test 2>&1 | tee -a work.log




Hm. Ok.


New missing dependencies:
- libppl.so.7()(64bit)
- libppl_c.so.2()(64bit)
- libmpfr.so.1()(64bit)
- glibc-headers
- glibc-headers = 2.12-1.209.el6


Notes:
- Perhaps { glibc-headers = 2.12-1.209.el6 } will also provide a symlink (?) for glibc-headers.
- libmpfr is probably the MPFR library.
- libppl is probably the Parma Polyhedra Library.




Search for each new item on pkgs.org.

Results:
- ppl-0.10.2-11.el6.x86_64.rpm (for both libppl.so.7()(64bit) and libppl_c.so.2()(64bit))
- mpfr-2.4.1-6.el6.x86_64.rpm
- glibc-headers-2.12-1.209.el6.x86_64.rpm (for glibc-headers. searching for "glibc-headers = 2.12-1.209.el6" produced no results)


Links:
centos.pkgs.org/6/centos-x86_64/ppl-0.10.2-11.el6.x86_64.rpm.html
centos.pkgs.org/6/centos-x86_64/mpfr-2.4.1-6.el6.x86_64.rpm.html
centos.pkgs.org/6/centos-x86_64/glibc-headers-2.12-1.209.el6.x86_64.rpm.html





Details on pkgs.org for each of these packages:




1) ppl-0.10.2-11.el6.x86_64.rpm

Description:

ppl - The Parma Polyhedra Library: a library of numerical abstractions

- Distribution: CentOS 6
- Repository: CentOS x86_64
- Package name: ppl
- Package version: 0.10.2
- Package release: 11.el6
- Package architecture: x86_64
- Package type: rpm
- Installed size: 4.42 MB
- Download size: 1.26 MB
- Official Mirror: mirror.centos.org

The Parma Polyhedra Library (PPL) is a library for the manipulation of (not necessarily closed) convex polyhedra and other numerical abstractions. The applications of convex polyhedra include program analysis, optimized compilation, integer and combinatorial optimization and statistical data-editing. The Parma Polyhedra Library comes with several user friendly interfaces, is fully dynamic (available virtual memory is the only limitation to the dimension of anything), written in accordance to all the applicable standards, exception-safe, rather efficient, thoroughly documented, and free software. This package provides all what is necessary to run applications using the PPL through its C and C++ interfaces.

Requires:
- /sbin/ldconfig
- libc.so.6(GLIBC_2.3.4)(64bit)
- libgcc_s.so.1()(64bit)
- libgcc_s.so.1(GCC_3.0)(64bit)
- libgmp.so.3()(64bit)
- libgmpxx.so.4()(64bit)
- libm.so.6()(64bit)
- libm.so.6(GLIBC_2.2.5)(64bit)
- libstdc++.so.6()(64bit)
- libstdc++.so.6(CXXABI_1.3)(64bit)
- libstdc++.so.6(GLIBCXX_3.4)(64bit)
- libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
- libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
- rtld(GNU_HASH)

Provides:
- libppl.so.7()(64bit)
- libppl_c.so.2()(64bit)
- ppl = 0.10.2-11.el6
- ppl(x86-64) = 0.10.2-11.el6

Download:
- Binary package: ppl-0.10.2-11.el6.x86_64.rpm
- Source package: ppl-0.10.2-11.el6.src.rpm

Files:
- /usr/bin/ppl-config
- /usr/lib64/libppl.so.7
- /usr/lib64/libppl.so.7.1.0
- /usr/lib64/libppl_c.so.2
- /usr/lib64/libppl_c.so.2.1.0
- /usr/lib64/ppl/
- /usr/share/doc/ppl-0.10.2/BUGS
- /usr/share/doc/ppl-0.10.2/COPYING
- /usr/share/doc/ppl-0.10.2/CREDITS
- /usr/share/doc/ppl-0.10.2/NEWS
- /usr/share/doc/ppl-0.10.2/README
- /usr/share/doc/ppl-0.10.2/README.configure
- /usr/share/doc/ppl-0.10.2/TODO
- /usr/share/doc/ppl-0.10.2/gpl.txt
- /usr/share/man/man1/ppl-config.1.gz




2) mpfr-2.4.1-6.el6.x86_64.rpm

Description:

mpfr - A C library for multiple-precision floating-point computations

- Distribution: CentOS 6
- Repository: CentOS x86_64
- Package name: mpfr
- Package version: 2.4.1
- Package release: 6.el6
- Package architecture: x86_64
- Package type: rpm
- Installed size: 368.53 KB
- Download size: 157.00 KB
- Official Mirror: mirror.centos.org

The MPFR library is a C library for multiple-precision floating-point computations with "correct rounding". The MPFR is efficient and also has a well-defined semantics. It copies the good ideas from the ANSI/IEEE-754 standard for double-precision floating-point arithmetic (53-bit mantissa). MPFR is based on the GMP multiple-precision library.

Requires:
- /sbin/ldconfig
- gmp >= 4.2.1
- libc.so.6(GLIBC_2.4)(64bit)
- libgmp.so.3()(64bit)
- rtld(GNU_HASH)

Provides:
- libmpfr.so.1()(64bit)
- mpfr = 2.4.1-6.el6
- mpfr(x86-64) = 2.4.1-6.el6

Download:
- Binary package: mpfr-2.4.1-6.el6.x86_64.rpm
- Source package: mpfr-2.4.1-6.el6.src.rpm

Files:
- /usr/lib64/libmpfr.so.1
- /usr/lib64/libmpfr.so.1.2.0
- /usr/share/doc/mpfr-2.4.1/COPYING
- /usr/share/doc/mpfr-2.4.1/COPYING.LIB
- /usr/share/doc/mpfr-2.4.1/NEWS
- /usr/share/doc/mpfr-2.4.1/README




3) glibc-headers-2.12-1.209.el6.x86_64.rpm

Description:

glibc-headers - Header files for development using standard C libraries

- Distribution: CentOS 6
- Repository: CentOS x86_64
- Package name: glibc-headers
- Package version: 2.12
- Package release: 1.209.el6
- Package architecture: x86_64
- Package type: rpm
- Installed size: 2.05 MB
- Download size: 619.36 KB
- Official Mirror: mirror.centos.org

The glibc-headers package contains the header files necessary for developing programs which use the standard C libraries (which are used by nearly all programs). If you are developing programs which will use the standard C libraries, your system needs to have these standard header files available in order to create the executables.

Install glibc-headers if you are going to develop programs which will use the standard C libraries.

Requires:
- glibc = 2.12-1.209.el6
- kernel-headers >= 2.2.1
- kernel-headers

Provides:
- glibc-headers = 2.12-1.209.el6
- glibc-headers(x86-64) = 2.12-1.209.el6
- glibc-headers(x86_64)

Obsoletes:
- glibc-headers(i586)
- glibc-headers(i686)

Download:
- Binary package: glibc-headers-2.12-1.209.el6.x86_64.rpm
- Source package: glibc-2.12-1.209.el6.src.rpm

Files:
/usr/include/_G_config.h
/usr/include/a.out.h
/usr/include/aio.h
/usr/include/aliases.h
/usr/include/alloca.h
/usr/include/ar.h
/usr/include/argp.h
/usr/include/argz.h
/usr/include/assert.h
/usr/include/byteswap.h
/usr/include/complex.h
/usr/include/cpio.h
/usr/include/crypt.h
/usr/include/ctype.h
/usr/include/dirent.h
/usr/include/dlfcn.h
/usr/include/elf.h
/usr/include/endian.h
/usr/include/envz.h
/usr/include/err.h
/usr/include/errno.h
/usr/include/error.h
/usr/include/execinfo.h
/usr/include/fcntl.h
/usr/include/features.h
/usr/include/fenv.h
/usr/include/fmtmsg.h
/usr/include/fnmatch.h
/usr/include/fpu_control.h
/usr/include/fstab.h
/usr/include/fts.h
/usr/include/ftw.h
/usr/include/gconv.h
/usr/include/getopt.h
/usr/include/glob.h
/usr/include/gnu-versions.h
/usr/include/grp.h
/usr/include/gshadow.h
/usr/include/iconv.h
/usr/include/ieee754.h
/usr/include/ifaddrs.h
/usr/include/inttypes.h
/usr/include/langinfo.h
/usr/include/lastlog.h
/usr/include/libgen.h
/usr/include/libintl.h
/usr/include/libio.h
/usr/include/limits.h
/usr/include/link.h
/usr/include/locale.h
/usr/include/malloc.h
/usr/include/math.h
/usr/include/mcheck.h
/usr/include/memory.h
/usr/include/mntent.h
/usr/include/monetary.h
/usr/include/mqueue.h
/usr/include/netdb.h
/usr/include/nl_types.h
/usr/include/nss.h
/usr/include/obstack.h
/usr/include/paths.h
/usr/include/poll.h
/usr/include/printf.h
/usr/include/pthread.h
/usr/include/pty.h
/usr/include/pwd.h
/usr/include/re_comp.h
/usr/include/regex.h
/usr/include/regexp.h
/usr/include/resolv.h
/usr/include/sched.h
/usr/include/search.h
/usr/include/semaphore.h
/usr/include/setjmp.h
/usr/include/sgtty.h
/usr/include/shadow.h
/usr/include/signal.h
/usr/include/spawn.h
/usr/include/stab.h
/usr/include/stdint.h
/usr/include/stdio.h
/usr/include/stdio_ext.h
/usr/include/stdlib.h
/usr/include/string.h
/usr/include/strings.h
/usr/include/syscall.h
/usr/include/sysexits.h
/usr/include/syslog.h
/usr/include/tar.h
/usr/include/termio.h
/usr/include/termios.h
/usr/include/tgmath.h
/usr/include/thread_db.h
/usr/include/time.h
/usr/include/ttyent.h
/usr/include/ucontext.h
/usr/include/ulimit.h
/usr/include/unistd.h
/usr/include/ustat.h
/usr/include/utime.h
/usr/include/utmp.h
/usr/include/utmpx.h
/usr/include/values.h
/usr/include/wait.h
/usr/include/wchar.h
/usr/include/wctype.h
/usr/include/wordexp.h
/usr/include/xlocale.h
/usr/include/arpa/ftp.h
/usr/include/arpa/inet.h
/usr/include/arpa/nameser.h
/usr/include/arpa/nameser_compat.h
/usr/include/arpa/telnet.h
/usr/include/arpa/tftp.h
/usr/include/bits/a.out.h
/usr/include/bits/byteswap.h
/usr/include/bits/cmathcalls.h
/usr/include/bits/confname.h
/usr/include/bits/dirent.h
/usr/include/bits/dlfcn.h
/usr/include/bits/elfclass.h
/usr/include/bits/endian.h
/usr/include/bits/environments.h
/usr/include/bits/errno.h
/usr/include/bits/error.h
/usr/include/bits/fcntl.h
/usr/include/bits/fcntl2.h
/usr/include/bits/fenv.h
/usr/include/bits/fenvinline.h
/usr/include/bits/huge_val.h
/usr/include/bits/huge_valf.h
/usr/include/bits/huge_vall.h
/usr/include/bits/in.h
/usr/include/bits/inf.h
/usr/include/bits/initspin.h
/usr/include/bits/ioctl-types.h
/usr/include/bits/ioctls.h
/usr/include/bits/ipc.h
/usr/include/bits/ipctypes.h
/usr/include/bits/libc-lock.h
/usr/include/bits/libio-ldbl.h
/usr/include/bits/link.h
/usr/include/bits/local_lim.h
/usr/include/bits/locale.h
/usr/include/bits/mathcalls.h
/usr/include/bits/mathdef.h
/usr/include/bits/mathinline.h
/usr/include/bits/mman.h
/usr/include/bits/monetary-ldbl.h
/usr/include/bits/mqueue.h
/usr/include/bits/mqueue2.h
/usr/include/bits/msq.h
/usr/include/bits/nan.h
/usr/include/bits/netdb.h
/usr/include/bits/poll.h
/usr/include/bits/posix1_lim.h
/usr/include/bits/posix2_lim.h
/usr/include/bits/posix_opt.h
/usr/include/bits/printf-ldbl.h
/usr/include/bits/pthreadtypes.h
/usr/include/bits/resource.h
/usr/include/bits/sched.h
/usr/include/bits/select.h
/usr/include/bits/sem.h
/usr/include/bits/semaphore.h
/usr/include/bits/setjmp.h
/usr/include/bits/setjmp2.h
/usr/include/bits/shm.h
/usr/include/bits/sigaction.h
/usr/include/bits/sigcontext.h
/usr/include/bits/siginfo.h
/usr/include/bits/signum.h
/usr/include/bits/sigset.h
/usr/include/bits/sigstack.h
/usr/include/bits/sigthread.h
/usr/include/bits/sockaddr.h
/usr/include/bits/socket.h
/usr/include/bits/socket2.h
/usr/include/bits/stab.def
/usr/include/bits/stat.h
/usr/include/bits/statfs.h
/usr/include/bits/statvfs.h
/usr/include/bits/stdio-ldbl.h
/usr/include/bits/stdio-lock.h
/usr/include/bits/stdio.h
/usr/include/bits/stdio2.h
/usr/include/bits/stdio_lim.h
/usr/include/bits/stdlib-ldbl.h
/usr/include/bits/stdlib.h
/usr/include/bits/string.h
/usr/include/bits/string2.h
/usr/include/bits/string3.h
/usr/include/bits/sys_errlist.h
/usr/include/bits/syscall.h
/usr/include/bits/syslog-ldbl.h
/usr/include/bits/syslog-path.h
/usr/include/bits/syslog.h
/usr/include/bits/termios.h
/usr/include/bits/time.h
/usr/include/bits/types.h
/usr/include/bits/typesizes.h
/usr/include/bits/uio.h
/usr/include/bits/unistd.h
/usr/include/bits/ustat.h
/usr/include/bits/utmp.h
/usr/include/bits/utmpx.h
/usr/include/bits/utsname.h
/usr/include/bits/waitflags.h
/usr/include/bits/waitstatus.h
/usr/include/bits/wchar-ldbl.h
/usr/include/bits/wchar.h
/usr/include/bits/wchar2.h
/usr/include/bits/wordsize.h
/usr/include/bits/xopen_lim.h
/usr/include/gnu/lib-names.h
/usr/include/gnu/libc-version.h
/usr/include/gnu/stubs.h
/usr/include/net/ethernet.h
/usr/include/net/if.h
/usr/include/net/if_arp.h
/usr/include/net/if_packet.h
/usr/include/net/if_ppp.h
/usr/include/net/if_shaper.h
/usr/include/net/if_slip.h
/usr/include/net/ppp-comp.h
/usr/include/net/ppp_defs.h
/usr/include/net/route.h
/usr/include/netash/ash.h
/usr/include/netatalk/at.h
/usr/include/netax25/ax25.h
/usr/include/neteconet/ec.h
/usr/include/netinet/ether.h
/usr/include/netinet/icmp6.h
/usr/include/netinet/if_ether.h
/usr/include/netinet/if_fddi.h
/usr/include/netinet/if_tr.h
/usr/include/netinet/igmp.h
/usr/include/netinet/in.h
/usr/include/netinet/in_systm.h
/usr/include/netinet/ip.h
/usr/include/netinet/ip6.h
/usr/include/netinet/ip_icmp.h
/usr/include/netinet/tcp.h
/usr/include/netinet/udp.h
/usr/include/netipx/ipx.h
/usr/include/netiucv/iucv.h
/usr/include/netpacket/packet.h
/usr/include/netrom/netrom.h
/usr/include/netrose/rose.h
/usr/include/nfs/nfs.h
/usr/include/protocols/routed.h
/usr/include/protocols/rwhod.h
/usr/include/protocols/talkd.h
/usr/include/protocols/timed.h
/usr/include/rpc/auth.h
/usr/include/rpc/auth_des.h
/usr/include/rpc/auth_unix.h
/usr/include/rpc/clnt.h
/usr/include/rpc/des_crypt.h
/usr/include/rpc/key_prot.h
/usr/include/rpc/netdb.h
/usr/include/rpc/pmap_clnt.h
/usr/include/rpc/pmap_prot.h
/usr/include/rpc/pmap_rmt.h
/usr/include/rpc/rpc.h
/usr/include/rpc/rpc_des.h
/usr/include/rpc/rpc_msg.h
/usr/include/rpc/svc.h
/usr/include/rpc/svc_auth.h
/usr/include/rpc/types.h
/usr/include/rpc/xdr.h
/usr/include/rpcsvc/bootparam.h
/usr/include/rpcsvc/bootparam_prot.h
/usr/include/rpcsvc/bootparam_prot.x
/usr/include/rpcsvc/key_prot.h
/usr/include/rpcsvc/key_prot.x
/usr/include/rpcsvc/klm_prot.h
/usr/include/rpcsvc/klm_prot.x
/usr/include/rpcsvc/mount.h
/usr/include/rpcsvc/mount.x
/usr/include/rpcsvc/nfs_prot.h
/usr/include/rpcsvc/nfs_prot.x
/usr/include/rpcsvc/nis.h
/usr/include/rpcsvc/nis.x
/usr/include/rpcsvc/nis_callback.h
/usr/include/rpcsvc/nis_callback.x
/usr/include/rpcsvc/nis_object.x
/usr/include/rpcsvc/nis_tags.h
/usr/include/rpcsvc/nislib.h
/usr/include/rpcsvc/nlm_prot.h
/usr/include/rpcsvc/nlm_prot.x
/usr/include/rpcsvc/rex.h
/usr/include/rpcsvc/rex.x
/usr/include/rpcsvc/rstat.h
/usr/include/rpcsvc/rstat.x
/usr/include/rpcsvc/rusers.h
/usr/include/rpcsvc/rusers.x
/usr/include/rpcsvc/sm_inter.h
/usr/include/rpcsvc/sm_inter.x
/usr/include/rpcsvc/spray.h
/usr/include/rpcsvc/spray.x
/usr/include/rpcsvc/yp.h
/usr/include/rpcsvc/yp.x
/usr/include/rpcsvc/yp_prot.h
/usr/include/rpcsvc/ypclnt.h
/usr/include/rpcsvc/yppasswd.h
/usr/include/rpcsvc/yppasswd.x
/usr/include/rpcsvc/ypupd.h
/usr/include/scsi/scsi.h
/usr/include/scsi/scsi_ioctl.h
/usr/include/scsi/sg.h
/usr/include/sys/acct.h
/usr/include/sys/bitypes.h
/usr/include/sys/cdefs.h
/usr/include/sys/debugreg.h
/usr/include/sys/dir.h
/usr/include/sys/epoll.h
/usr/include/sys/errno.h
/usr/include/sys/eventfd.h
/usr/include/sys/fcntl.h
/usr/include/sys/file.h
/usr/include/sys/fsuid.h
/usr/include/sys/gmon.h
/usr/include/sys/gmon_out.h
/usr/include/sys/inotify.h
/usr/include/sys/io.h
/usr/include/sys/ioctl.h
/usr/include/sys/ipc.h
/usr/include/sys/kd.h
/usr/include/sys/kdaemon.h
/usr/include/sys/klog.h
/usr/include/sys/mman.h
/usr/include/sys/mount.h
/usr/include/sys/msg.h
/usr/include/sys/mtio.h
/usr/include/sys/param.h
/usr/include/sys/pci.h
/usr/include/sys/perm.h
/usr/include/sys/personality.h
/usr/include/sys/poll.h
/usr/include/sys/prctl.h
/usr/include/sys/procfs.h
/usr/include/sys/profil.h
/usr/include/sys/ptrace.h
/usr/include/sys/queue.h
/usr/include/sys/quota.h
/usr/include/sys/raw.h
/usr/include/sys/reboot.h
/usr/include/sys/reg.h
/usr/include/sys/resource.h
/usr/include/sys/select.h
/usr/include/sys/sem.h
/usr/include/sys/sendfile.h
/usr/include/sys/shm.h
/usr/include/sys/signal.h
/usr/include/sys/signalfd.h
/usr/include/sys/socket.h
/usr/include/sys/socketvar.h
/usr/include/sys/soundcard.h
/usr/include/sys/stat.h
/usr/include/sys/statfs.h
/usr/include/sys/statvfs.h
/usr/include/sys/swap.h
/usr/include/sys/syscall.h
/usr/include/sys/sysctl.h
/usr/include/sys/sysinfo.h
/usr/include/sys/syslog.h
/usr/include/sys/sysmacros.h
/usr/include/sys/termios.h
/usr/include/sys/time.h
/usr/include/sys/timeb.h
/usr/include/sys/timerfd.h
/usr/include/sys/times.h
/usr/include/sys/timex.h
/usr/include/sys/ttychars.h
/usr/include/sys/ttydefaults.h
/usr/include/sys/types.h
/usr/include/sys/ucontext.h
/usr/include/sys/uio.h
/usr/include/sys/ultrasound.h
/usr/include/sys/un.h
/usr/include/sys/unistd.h
/usr/include/sys/user.h
/usr/include/sys/ustat.h
/usr/include/sys/utsname.h
/usr/include/sys/vfs.h
/usr/include/sys/vlimit.h
/usr/include/sys/vt.h
/usr/include/sys/vtimes.h
/usr/include/sys/wait.h
/usr/include/sys/xattr.h







On Aineko, click the linked binary package file in the Download section of each package page on pkgs.org.




Transfer all the binary rpm package files to Kalkin.


Package list:
- glibc-headers-2.12-1.209.el6.x86_64.rpm
- mpfr-2.4.1-6.el6.x86_64.rpm
- ppl-0.10.2-11.el6.x86_64.rpm

ppl-0.10.2-11.el6.x86_64.rpm provides:
- libppl.so.7()(64bit)
- libppl_c.so.2()(64bit)

mpfr-2.4.1-6.el6.x86_64.rpm provides:
- libmpfr.so.1()(64bit)

glibc-headers-2.12-1.209.el6.x86_64.rpm provides:
- glibc-headers = 2.12-1.209.el6
- glibc-headers(x86-64) = 2.12-1.209.el6
- glibc-headers(x86_64)


Missing dependencies reported earlier when --test installing:
- libppl.so.7()(64bit)
- libppl_c.so.2()(64bit)
- libmpfr.so.1()(64bit)
- glibc-headers
- glibc-headers = 2.12-1.209.el6


Perhaps providing glibc-headers(x86_64) will be equivalent to providing glibc-headers.






Next: Check the signature of each new rpm package.

[root@kalkin work]# rpm --checksig rpms/glibc-headers-2.12-1.209.el6.x86_64.rpm --verbose

rpms/glibc-headers-2.12-1.209.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: OK Header SHA1 digest: OK (b7ecb410973b5e44ccd2bb39594c8ee01ead02a6) V3 RSA/SHA1 Signature, key ID c105b9de: OK MD5 digest: OK (9c314b67910ba8ee9a2a3017c8562e56)


[root@kalkin work]# rpm --checksig rpms/mpfr-2.4.1-6.el6.x86_64.rpm --verbose

rpms/mpfr-2.4.1-6.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID c105b9de: OK Header SHA1 digest: OK (9851c8988a88308d82a3070bd868db0cdc7d07ad) V3 RSA/SHA256 Signature, key ID c105b9de: OK MD5 digest: OK (962fa85bfb231914eb135da3bb9785a7)


[root@kalkin work]# rpm --checksig rpms/ppl-0.10.2-11.el6.x86_64.rpm --verbose

rpms/ppl-0.10.2-11.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID c105b9de: OK Header SHA1 digest: OK (d5e312340e41dc25ec5b54d9a6abf8cc05ae7045) V3 RSA/SHA256 Signature, key ID c105b9de: OK MD5 digest: OK (6d4d70bb01ebe2ffc3a9cf5e27da20cb)



Notes:
- All signatures are valid.
- Both signatures in all four packages have key ID == c105b9de (i.e. the Centos 6 signing key's key ID).
- The signatures for the mpfr and ppl packages are RSA/SHA256 instead of RSA/SHA1.



Next: Run a --test install for each new package. Note which dependencies, if any, are lacking for each of them on the system.



[root@kalkin work]# rpm --install rpms/glibc-headers-2.12-1.209.el6.x86_64.rpm --test

error: Failed dependencies: kernel-headers is needed by glibc-headers-2.12-1.209.el6.x86_64 kernel-headers >= 2.2.1 is needed by glibc-headers-2.12-1.209.el6.x86_64


[root@kalkin work]# rpm --install rpms/mpfr-2.4.1-6.el6.x86_64.rpm --test


[root@kalkin work]# rpm --install rpms/ppl-0.10.2-11.el6.x86_64.rpm --test




New missing dependencies:
- kernel-headers
- kernel-headers >= 2.2.1


Search for each new item on pkgs.org.



Results:
- [Centos 6 Centos x86_64 option] kernel-headers-2.6.32-696.el6.x86_64.rpm (for kernel-headers. searching for "kernel-headers >= 2.2.1" produced no results.).


Link:
centos.pkgs.org/6/centos-x86_64/kernel-headers-2.6.32-696.el6.x86_64.rpm.html



Details on pkgs.org for this package:




1) kernel-headers-2.6.32-696.el6.x86_64.rpm

Description:

kernel-headers - Header files for the Linux kernel for use by glibc

- Distribution: CentOS 6
- Repository: CentOS x86_64
- Package name: kernel-headers
- Package version: 2.6.32
- Package release: 696.el6
- Package architecture: x86_64
- Package type: rpm
- Installed size: 2.65 MB
- Download size: 4.46 MB
- Official Mirror: mirror.centos.org

Kernel-headers includes the C header files that specify the interface between the Linux kernel and userspace libraries and programs. The header files define structures and constants that are needed for building most standard programs and are also needed for rebuilding the glibc package.

Provides:
- glibc-kernheaders = 3.0-46
- kernel-headers = 2.6.32-696.el6
- kernel-headers(x86-64) = 2.6.32-696.el6

Obsoletes:
- glibc-kernheaders

Download:
- Binary package: kernel-headers-2.6.32-696.el6.x86_64.rpm
- Source package: kernel-2.6.32-696.el6.src.rpm

Files:
- /usr/include/asm/a.out.h
- /usr/include/asm/auxvec.h
- /usr/include/asm/bitsperlong.h
- /usr/include/asm/boot.h
- /usr/include/asm/bootparam.h
- /usr/include/asm/byteorder.h
- /usr/include/asm/debugreg.h
- /usr/include/asm/e820.h
- /usr/include/asm/errno.h
- /usr/include/asm/fcntl.h
- /usr/include/asm/hyperv.h
- /usr/include/asm/ioctl.h
- /usr/include/asm/ioctls.h
- /usr/include/asm/ipcbuf.h
- /usr/include/asm/ist.h
- /usr/include/asm/kvm.h
- /usr/include/asm/kvm_para.h
- /usr/include/asm/ldt.h
- /usr/include/asm/mce.h
- /usr/include/asm/mman.h
- /usr/include/asm/msgbuf.h
- /usr/include/asm/msr-index.h
- /usr/include/asm/msr.h
- /usr/include/asm/mtrr.h
- /usr/include/asm/param.h
- /usr/include/asm/poll.h
- /usr/include/asm/posix_types.h
- /usr/include/asm/posix_types_32.h
- /usr/include/asm/posix_types_64.h
- /usr/include/asm/prctl.h
- /usr/include/asm/processor-flags.h
- /usr/include/asm/ptrace-abi.h
- /usr/include/asm/ptrace.h
- /usr/include/asm/resource.h
- /usr/include/asm/sembuf.h
- /usr/include/asm/setup.h
- /usr/include/asm/shmbuf.h
- /usr/include/asm/sigcontext.h
- /usr/include/asm/sigcontext32.h
- /usr/include/asm/siginfo.h
- /usr/include/asm/signal.h
- /usr/include/asm/socket.h
- /usr/include/asm/sockios.h
- /usr/include/asm/stat.h
- /usr/include/asm/statfs.h
- /usr/include/asm/swab.h
- /usr/include/asm/termbits.h
- /usr/include/asm/termios.h
- /usr/include/asm/types.h
- /usr/include/asm/ucontext.h
- /usr/include/asm/unistd.h
- /usr/include/asm/unistd_32.h
- /usr/include/asm/unistd_64.h
- /usr/include/asm/vm86.h
- /usr/include/asm/vsyscall.h
- /usr/include/asm-generic/auxvec.h
- /usr/include/asm-generic/bitsperlong.h
- /usr/include/asm-generic/errno-base.h
- /usr/include/asm-generic/errno.h
- /usr/include/asm-generic/fcntl.h
- /usr/include/asm-generic/int-l64.h
- /usr/include/asm-generic/int-ll64.h
- /usr/include/asm-generic/ioctl.h
- /usr/include/asm-generic/ioctls.h
- /usr/include/asm-generic/ipcbuf.h
- /usr/include/asm-generic/mman-common.h
- /usr/include/asm-generic/mman.h
- /usr/include/asm-generic/msgbuf.h
- /usr/include/asm-generic/param.h
- /usr/include/asm-generic/poll.h
- /usr/include/asm-generic/posix_types.h
- /usr/include/asm-generic/resource.h
- /usr/include/asm-generic/sembuf.h
- /usr/include/asm-generic/setup.h
- /usr/include/asm-generic/shmbuf.h
- /usr/include/asm-generic/shmparam.h
- /usr/include/asm-generic/siginfo.h
- /usr/include/asm-generic/signal-defs.h
- /usr/include/asm-generic/signal.h
- /usr/include/asm-generic/socket.h
- /usr/include/asm-generic/sockios.h
- /usr/include/asm-generic/stat.h
- /usr/include/asm-generic/statfs.h
- /usr/include/asm-generic/swab.h
- /usr/include/asm-generic/termbits.h
- /usr/include/asm-generic/termios.h
- /usr/include/asm-generic/types.h
- /usr/include/asm-generic/ucontext.h
- /usr/include/asm-generic/unistd.h
- /usr/include/drm/drm.h
- /usr/include/drm/drm_fourcc.h
- /usr/include/drm/drm_mode.h
- /usr/include/drm/drm_sarea.h
- /usr/include/drm/i810_drm.h
- /usr/include/drm/i915_drm.h
- /usr/include/drm/mga_drm.h
- /usr/include/drm/nouveau_drm.h
- /usr/include/drm/r128_drm.h
- /usr/include/drm/radeon_drm.h
- /usr/include/drm/savage_drm.h
- /usr/include/drm/sis_drm.h
- /usr/include/drm/via_drm.h
- /usr/include/linux/a.out.h
- /usr/include/linux/acct.h
- /usr/include/linux/adb.h
- /usr/include/linux/adfs_fs.h
- /usr/include/linux/affs_hardblocks.h
- /usr/include/linux/agpgart.h
- /usr/include/linux/aio_abi.h
- /usr/include/linux/apm_bios.h
- /usr/include/linux/arcfb.h
- /usr/include/linux/atalk.h
- /usr/include/linux/atm.h
- /usr/include/linux/atm_eni.h
- /usr/include/linux/atm_he.h
- /usr/include/linux/atm_idt77105.h
- /usr/include/linux/atm_nicstar.h
- /usr/include/linux/atm_tcp.h
- /usr/include/linux/atm_zatm.h
- /usr/include/linux/atmapi.h
- /usr/include/linux/atmarp.h
- /usr/include/linux/atmbr2684.h
- /usr/include/linux/atmclip.h
- /usr/include/linux/atmdev.h
- /usr/include/linux/atmioc.h
- /usr/include/linux/atmlec.h
- /usr/include/linux/atmmpc.h
- /usr/include/linux/atmppp.h
- /usr/include/linux/atmsap.h
- /usr/include/linux/atmsvc.h
- /usr/include/linux/audit.h
- /usr/include/linux/auto_fs.h
- /usr/include/linux/auto_fs4.h
- /usr/include/linux/auxvec.h
- /usr/include/linux/ax25.h
- /usr/include/linux/b1lli.h
- /usr/include/linux/baycom.h
- /usr/include/linux/bfs_fs.h
- /usr/include/linux/binfmts.h
- /usr/include/linux/blk_types.h
- /usr/include/linux/blkpg.h
- /usr/include/linux/blktrace_api.h
- /usr/include/linux/bpqether.h
- /usr/include/linux/bsg.h
- /usr/include/linux/can.h
- /usr/include/linux/capability.h
- /usr/include/linux/capi.h
- /usr/include/linux/cciss_ioctl.h
- /usr/include/linux/cdk.h
- /usr/include/linux/cdrom.h
- /usr/include/linux/cgroupstats.h
- /usr/include/linux/chio.h
- /usr/include/linux/cm4000_cs.h
- /usr/include/linux/cn_proc.h
- /usr/include/linux/coda.h
- /usr/include/linux/coda_psdev.h
- /usr/include/linux/coff.h
- /usr/include/linux/comstats.h
- /usr/include/linux/connector.h
- /usr/include/linux/const.h
- /usr/include/linux/cramfs_fs.h
- /usr/include/linux/cuda.h
- /usr/include/linux/cyclades.h
- /usr/include/linux/cycx_cfm.h
- /usr/include/linux/dcbnl.h
- /usr/include/linux/dccp.h
- /usr/include/linux/dlm.h
- /usr/include/linux/dlm_device.h
- /usr/include/linux/dlm_netlink.h
- /usr/include/linux/dlm_plock.h
- /usr/include/linux/dlmconstants.h
- /usr/include/linux/dm-ioctl.h
- /usr/include/linux/dm-log-userspace.h
- /usr/include/linux/dn.h
- /usr/include/linux/dqblk_xfs.h
- /usr/include/linux/edd.h
- /usr/include/linux/efs_fs_sb.h
- /usr/include/linux/elf-em.h
- /usr/include/linux/elf-fdpic.h
- /usr/include/linux/elf.h
- /usr/include/linux/elfcore.h
- /usr/include/linux/errno.h
- /usr/include/linux/errqueue.h
- /usr/include/linux/ethtool.h
- /usr/include/linux/eventpoll.h
- /usr/include/linux/ext2_fs.h
- /usr/include/linux/fadvise.h
- /usr/include/linux/falloc.h
- /usr/include/linux/fb.h
- /usr/include/linux/fcntl.h
- /usr/include/linux/fd.h
- /usr/include/linux/fdreg.h
- /usr/include/linux/fib_rules.h
- /usr/include/linux/fiemap.h
- /usr/include/linux/filter.h
- /usr/include/linux/firewire-cdev.h
- /usr/include/linux/firewire-constants.h
- /usr/include/linux/flat.h
- /usr/include/linux/fs.h
- /usr/include/linux/fuse.h
- /usr/include/linux/futex.h
- /usr/include/linux/gameport.h
- /usr/include/linux/gen_stats.h
- /usr/include/linux/generic_serial.h
- /usr/include/linux/genetlink.h
- /usr/include/linux/gfs2_ondisk.h
- /usr/include/linux/gigaset_dev.h
- /usr/include/linux/hayesesp.h
- /usr/include/linux/hdlc.h
- /usr/include/linux/hdlcdrv.h
- /usr/include/linux/hdreg.h
- /usr/include/linux/hid.h
- /usr/include/linux/hiddev.h
- /usr/include/linux/hidraw.h
- /usr/include/linux/hpet.h
- /usr/include/linux/hysdn_if.h
- /usr/include/linux/i2c-dev.h
- /usr/include/linux/i2c.h
- /usr/include/linux/i2o-dev.h
- /usr/include/linux/i8k.h
- /usr/include/linux/icmp.h
- /usr/include/linux/icmpv6.h
- /usr/include/linux/if.h
- /usr/include/linux/if_addr.h
- /usr/include/linux/if_addrlabel.h
- /usr/include/linux/if_arcnet.h
- /usr/include/linux/if_arp.h
- /usr/include/linux/if_bonding.h
- /usr/include/linux/if_bridge.h
- /usr/include/linux/if_cablemodem.h
- /usr/include/linux/if_ec.h
- /usr/include/linux/if_eql.h
- /usr/include/linux/if_ether.h
- /usr/include/linux/if_fc.h
- /usr/include/linux/if_fddi.h
- /usr/include/linux/if_frad.h
- /usr/include/linux/if_hippi.h
- /usr/include/linux/if_infiniband.h
- /usr/include/linux/if_link.h
- /usr/include/linux/if_ltalk.h
- /usr/include/linux/if_packet.h
- /usr/include/linux/if_phonet.h
- /usr/include/linux/if_plip.h
- /usr/include/linux/if_ppp.h
- /usr/include/linux/if_pppol2tp.h
- /usr/include/linux/if_pppox.h
- /usr/include/linux/if_slip.h
- /usr/include/linux/if_strip.h
- /usr/include/linux/if_tr.h
- /usr/include/linux/if_tun.h
- /usr/include/linux/if_tunnel.h
- /usr/include/linux/if_vlan.h
- /usr/include/linux/igmp.h
- /usr/include/linux/in.h
- /usr/include/linux/in6.h
- /usr/include/linux/in_route.h
- /usr/include/linux/inet_diag.h
- /usr/include/linux/inotify.h
- /usr/include/linux/input.h
- /usr/include/linux/ioctl.h
- /usr/include/linux/ip.h
- /usr/include/linux/ip6_tunnel.h
- /usr/include/linux/ip_vs.h
- /usr/include/linux/ipc.h
- /usr/include/linux/ipmi.h
- /usr/include/linux/ipmi_msgdefs.h
- /usr/include/linux/ipsec.h
- /usr/include/linux/ipv6.h
- /usr/include/linux/ipv6_route.h
- /usr/include/linux/ipx.h
- /usr/include/linux/irda.h
- /usr/include/linux/irqnr.h
- /usr/include/linux/isdn.h
- /usr/include/linux/isdn_divertif.h
- /usr/include/linux/isdn_ppp.h
- /usr/include/linux/isdnif.h
- /usr/include/linux/iso_fs.h
- /usr/include/linux/ivtv.h
- /usr/include/linux/ivtvfb.h
- /usr/include/linux/ixjuser.h
- /usr/include/linux/jffs2.h
- /usr/include/linux/joystick.h
- /usr/include/linux/kd.h
- /usr/include/linux/kdev_t.h
- /usr/include/linux/kernel.h
- /usr/include/linux/kernelcapi.h
- /usr/include/linux/keyboard.h
- /usr/include/linux/keyctl.h
- /usr/include/linux/kvm.h
- /usr/include/linux/kvm_para.h
- /usr/include/linux/libc-compat.h
- /usr/include/linux/limits.h
- /usr/include/linux/llc.h
- /usr/include/linux/loop.h
- /usr/include/linux/lp.h
- /usr/include/linux/magic.h
- /usr/include/linux/major.h
- /usr/include/linux/map_to_7segment.h
- /usr/include/linux/matroxfb.h
- /usr/include/linux/mempolicy.h
- /usr/include/linux/meye.h
- /usr/include/linux/mii.h
- /usr/include/linux/minix_fs.h
- /usr/include/linux/mman.h
- /usr/include/linux/mmtimer.h
- /usr/include/linux/mqueue.h
- /usr/include/linux/mroute.h
- /usr/include/linux/mroute6.h
- /usr/include/linux/msdos_fs.h
- /usr/include/linux/msg.h
- /usr/include/linux/mtio.h
- /usr/include/linux/n_r3964.h
- /usr/include/linux/nbd.h
- /usr/include/linux/ncp.h
- /usr/include/linux/ncp_fs.h
- /usr/include/linux/ncp_mount.h
- /usr/include/linux/ncp_no.h
- /usr/include/linux/neighbour.h
- /usr/include/linux/net.h
- /usr/include/linux/net_dropmon.h
- /usr/include/linux/net_tstamp.h
- /usr/include/linux/netdevice.h
- /usr/include/linux/netfilter.h
- /usr/include/linux/netfilter_arp.h
- /usr/include/linux/netfilter_bridge.h
- /usr/include/linux/netfilter_decnet.h
- /usr/include/linux/netfilter_ipv4.h
- /usr/include/linux/netfilter_ipv6.h
- /usr/include/linux/netlink.h
- /usr/include/linux/netrom.h
- /usr/include/linux/nfs.h
- /usr/include/linux/nfs2.h
- /usr/include/linux/nfs3.h
- /usr/include/linux/nfs4.h
- /usr/include/linux/nfs4_mount.h
- /usr/include/linux/nfs_fs.h
- /usr/include/linux/nfs_idmap.h
- /usr/include/linux/nfs_mount.h
- /usr/include/linux/nfsacl.h
- /usr/include/linux/nl80211.h
- /usr/include/linux/nubus.h
- /usr/include/linux/nvram.h
- /usr/include/linux/oom.h
- /usr/include/linux/param.h
- /usr/include/linux/parport.h
- /usr/include/linux/patchkey.h
- /usr/include/linux/pci.h
- /usr/include/linux/pci_regs.h
- /usr/include/linux/perf_event.h
- /usr/include/linux/personality.h
- /usr/include/linux/pfkeyv2.h
- /usr/include/linux/pg.h
- /usr/include/linux/phantom.h
- /usr/include/linux/phonet.h
- /usr/include/linux/pkt_cls.h
- /usr/include/linux/pkt_sched.h
- /usr/include/linux/pktcdvd.h
- /usr/include/linux/pmu.h
- /usr/include/linux/poll.h
- /usr/include/linux/posix_types.h
- /usr/include/linux/ppdev.h
- /usr/include/linux/ppp-comp.h
- /usr/include/linux/ppp_defs.h
- /usr/include/linux/pps.h
- /usr/include/linux/prctl.h
- /usr/include/linux/ptp_clock.h
- /usr/include/linux/ptrace.h
- /usr/include/linux/qnx4_fs.h
- /usr/include/linux/qnxtypes.h
- /usr/include/linux/quota.h
- /usr/include/linux/radeonfb.h
- /usr/include/linux/random.h
- /usr/include/linux/raw.h
- /usr/include/linux/reboot.h
- /usr/include/linux/reiserfs_fs.h
- /usr/include/linux/reiserfs_xattr.h
- /usr/include/linux/resource.h
- /usr/include/linux/rfkill.h
- /usr/include/linux/romfs_fs.h
- /usr/include/linux/rose.h
- /usr/include/linux/route.h
- /usr/include/linux/rtc.h
- /usr/include/linux/rtnetlink.h
- /usr/include/linux/scc.h
- /usr/include/linux/sched.h
- /usr/include/linux/screen_info.h
- /usr/include/linux/sdla.h
- /usr/include/linux/selinux_netlink.h
- /usr/include/linux/sem.h
- /usr/include/linux/serial.h
- /usr/include/linux/serial_core.h
- /usr/include/linux/serial_reg.h
- /usr/include/linux/serio.h
- /usr/include/linux/shm.h
- /usr/include/linux/signal.h
- /usr/include/linux/signalfd.h
- /usr/include/linux/smb.h
- /usr/include/linux/smb_fs.h
- /usr/include/linux/smb_mount.h
- /usr/include/linux/smbno.h
- /usr/include/linux/snmp.h
- /usr/include/linux/socket.h
- /usr/include/linux/sockios.h
- /usr/include/linux/som.h
- /usr/include/linux/sonet.h
- /usr/include/linux/sonypi.h
- /usr/include/linux/sound.h
- /usr/include/linux/soundcard.h
- /usr/include/linux/stat.h
- /usr/include/linux/stddef.h
- /usr/include/linux/string.h
- /usr/include/linux/suspend_ioctls.h
- /usr/include/linux/swab.h
- /usr/include/linux/synclink.h
- /usr/include/linux/sysctl.h
- /usr/include/linux/taskstats.h
- /usr/include/linux/tcp.h
- /usr/include/linux/telephony.h
- /usr/include/linux/termios.h
- /usr/include/linux/time.h
- /usr/include/linux/times.h
- /usr/include/linux/timex.h
- /usr/include/linux/tiocl.h
- /usr/include/linux/tipc.h
- /usr/include/linux/tipc_config.h
- /usr/include/linux/toshiba.h
- /usr/include/linux/tty.h
- /usr/include/linux/types.h
- /usr/include/linux/udf_fs_i.h
- /usr/include/linux/udp.h
- /usr/include/linux/uinput.h
- /usr/include/linux/uio.h
- /usr/include/linux/ultrasound.h
- /usr/include/linux/un.h
- /usr/include/linux/unistd.h
- /usr/include/linux/usbdevice_fs.h
- /usr/include/linux/utime.h
- /usr/include/linux/utsname.h
- /usr/include/linux/uuid.h
- /usr/include/linux/version.h
- /usr/include/linux/veth.h
- /usr/include/linux/vhost.h
- /usr/include/linux/videodev.h
- /usr/include/linux/videodev2.h
- /usr/include/linux/videotext.h
- /usr/include/linux/virtio_9p.h
- /usr/include/linux/virtio_balloon.h
- /usr/include/linux/virtio_blk.h
- /usr/include/linux/virtio_config.h
- /usr/include/linux/virtio_console.h
- /usr/include/linux/virtio_ids.h
- /usr/include/linux/virtio_net.h
- /usr/include/linux/virtio_pci.h
- /usr/include/linux/virtio_ring.h
- /usr/include/linux/virtio_rng.h
- /usr/include/linux/vt.h
- /usr/include/linux/wait.h
- /usr/include/linux/wanrouter.h
- /usr/include/linux/watchdog.h
- /usr/include/linux/wimax.h
- /usr/include/linux/wireless.h
- /usr/include/linux/x25.h
- /usr/include/linux/xattr.h
- /usr/include/linux/xfrm.h
- /usr/include/linux/byteorder/big_endian.h
- /usr/include/linux/byteorder/little_endian.h
- /usr/include/linux/can/bcm.h
- /usr/include/linux/can/error.h
- /usr/include/linux/can/netlink.h
- /usr/include/linux/can/raw.h
- /usr/include/linux/dvb/audio.h
- /usr/include/linux/dvb/ca.h
- /usr/include/linux/dvb/dmx.h
- /usr/include/linux/dvb/frontend.h
- /usr/include/linux/dvb/net.h
- /usr/include/linux/dvb/osd.h
- /usr/include/linux/dvb/version.h
- /usr/include/linux/dvb/video.h
- /usr/include/linux/hdlc/ioctl.h
- /usr/include/linux/isdn/capicmd.h
- /usr/include/linux/netfilter/nf_conntrack_common.h
- /usr/include/linux/netfilter/nf_conntrack_ftp.h
- /usr/include/linux/netfilter/nf_conntrack_sctp.h
- /usr/include/linux/netfilter/nf_conntrack_tcp.h
- /usr/include/linux/netfilter/nf_conntrack_tuple_common.h
- /usr/include/linux/netfilter/nfnetlink.h
- /usr/include/linux/netfilter/nfnetlink_compat.h
- /usr/include/linux/netfilter/nfnetlink_conntrack.h
- /usr/include/linux/netfilter/nfnetlink_log.h
- /usr/include/linux/netfilter/nfnetlink_queue.h
- /usr/include/linux/netfilter/x_tables.h
- /usr/include/linux/netfilter/xt_AUDIT.h
- /usr/include/linux/netfilter/xt_CHECKSUM.h
- /usr/include/linux/netfilter/xt_CLASSIFY.h
- /usr/include/linux/netfilter/xt_CONNMARK.h
- /usr/include/linux/netfilter/xt_CONNSECMARK.h
- /usr/include/linux/netfilter/xt_DSCP.h
- /usr/include/linux/netfilter/xt_LED.h
- /usr/include/linux/netfilter/xt_MARK.h
- /usr/include/linux/netfilter/xt_NFLOG.h
- /usr/include/linux/netfilter/xt_NFQUEUE.h
- /usr/include/linux/netfilter/xt_RATEEST.h
- /usr/include/linux/netfilter/xt_SECMARK.h
- /usr/include/linux/netfilter/xt_TCPMSS.h
- /usr/include/linux/netfilter/xt_TCPOPTSTRIP.h
- /usr/include/linux/netfilter/xt_TPROXY.h
- /usr/include/linux/netfilter/xt_cluster.h
- /usr/include/linux/netfilter/xt_comment.h
- /usr/include/linux/netfilter/xt_connbytes.h
- /usr/include/linux/netfilter/xt_connlimit.h
- /usr/include/linux/netfilter/xt_connmark.h
- /usr/include/linux/netfilter/xt_conntrack.h
- /usr/include/linux/netfilter/xt_dccp.h
- /usr/include/linux/netfilter/xt_dscp.h
- /usr/include/linux/netfilter/xt_esp.h
- /usr/include/linux/netfilter/xt_hashlimit.h
- /usr/include/linux/netfilter/xt_helper.h
- /usr/include/linux/netfilter/xt_iprange.h
- /usr/include/linux/netfilter/xt_length.h
- /usr/include/linux/netfilter/xt_limit.h
- /usr/include/linux/netfilter/xt_mac.h
- /usr/include/linux/netfilter/xt_mark.h
- /usr/include/linux/netfilter/xt_multiport.h
- /usr/include/linux/netfilter/xt_osf.h
- /usr/include/linux/netfilter/xt_owner.h
- /usr/include/linux/netfilter/xt_physdev.h
- /usr/include/linux/netfilter/xt_pkttype.h
- /usr/include/linux/netfilter/xt_policy.h
- /usr/include/linux/netfilter/xt_quota.h
- /usr/include/linux/netfilter/xt_rateest.h
- /usr/include/linux/netfilter/xt_realm.h
- /usr/include/linux/netfilter/xt_recent.h
- /usr/include/linux/netfilter/xt_sctp.h
- /usr/include/linux/netfilter/xt_set.h
- /usr/include/linux/netfilter/xt_state.h
- /usr/include/linux/netfilter/xt_statistic.h
- /usr/include/linux/netfilter/xt_string.h
- /usr/include/linux/netfilter/xt_tcpmss.h
- /usr/include/linux/netfilter/xt_tcpudp.h
- /usr/include/linux/netfilter/xt_time.h
- /usr/include/linux/netfilter/xt_u32.h
- /usr/include/linux/netfilter/ipset/ip_set.h
- /usr/include/linux/netfilter/ipset/ip_set_bitmap.h
- /usr/include/linux/netfilter/ipset/ip_set_hash.h
- /usr/include/linux/netfilter/ipset/ip_set_list.h
- /usr/include/linux/netfilter_arp/arp_tables.h
- /usr/include/linux/netfilter_arp/arpt_mangle.h
- /usr/include/linux/netfilter_bridge/ebt_802_3.h
- /usr/include/linux/netfilter_bridge/ebt_among.h
- /usr/include/linux/netfilter_bridge/ebt_arp.h
- /usr/include/linux/netfilter_bridge/ebt_arpreply.h
- /usr/include/linux/netfilter_bridge/ebt_ip.h
- /usr/include/linux/netfilter_bridge/ebt_limit.h
- /usr/include/linux/netfilter_bridge/ebt_log.h
- /usr/include/linux/netfilter_bridge/ebt_mark_m.h
- /usr/include/linux/netfilter_bridge/ebt_mark_t.h
- /usr/include/linux/netfilter_bridge/ebt_nat.h
- /usr/include/linux/netfilter_bridge/ebt_pkttype.h
- /usr/include/linux/netfilter_bridge/ebt_redirect.h
- /usr/include/linux/netfilter_bridge/ebt_stp.h
- /usr/include/linux/netfilter_bridge/ebt_ulog.h
- /usr/include/linux/netfilter_bridge/ebt_vlan.h
- /usr/include/linux/netfilter_bridge/ebtables.h
- /usr/include/linux/netfilter_ipv4/ip_queue.h
- /usr/include/linux/netfilter_ipv4/ip_tables.h
- /usr/include/linux/netfilter_ipv4/ipt_CLUSTERIP.h
- /usr/include/linux/netfilter_ipv4/ipt_ECN.h
- /usr/include/linux/netfilter_ipv4/ipt_LOG.h
- /usr/include/linux/netfilter_ipv4/ipt_REJECT.h
- /usr/include/linux/netfilter_ipv4/ipt_SAME.h
- /usr/include/linux/netfilter_ipv4/ipt_TTL.h
- /usr/include/linux/netfilter_ipv4/ipt_ULOG.h
- /usr/include/linux/netfilter_ipv4/ipt_addrtype.h
- /usr/include/linux/netfilter_ipv4/ipt_ah.h
- /usr/include/linux/netfilter_ipv4/ipt_ecn.h
- /usr/include/linux/netfilter_ipv4/ipt_realm.h
- /usr/include/linux/netfilter_ipv4/ipt_ttl.h
- /usr/include/linux/netfilter_ipv6/ip6_tables.h
- /usr/include/linux/netfilter_ipv6/ip6t_HL.h
- /usr/include/linux/netfilter_ipv6/ip6t_LOG.h
- /usr/include/linux/netfilter_ipv6/ip6t_REJECT.h
- /usr/include/linux/netfilter_ipv6/ip6t_ah.h
- /usr/include/linux/netfilter_ipv6/ip6t_frag.h
- /usr/include/linux/netfilter_ipv6/ip6t_hl.h
- /usr/include/linux/netfilter_ipv6/ip6t_ipv6header.h
- /usr/include/linux/netfilter_ipv6/ip6t_mh.h
- /usr/include/linux/netfilter_ipv6/ip6t_opts.h
- /usr/include/linux/netfilter_ipv6/ip6t_rt.h
- /usr/include/linux/nfsd/const.h
- /usr/include/linux/nfsd/debug.h
- /usr/include/linux/nfsd/export.h
- /usr/include/linux/nfsd/nfsfh.h
- /usr/include/linux/nfsd/stats.h
- /usr/include/linux/nfsd/syscall.h
- /usr/include/linux/raid/md_p.h
- /usr/include/linux/raid/md_u.h
- /usr/include/linux/spi/spidev.h
- /usr/include/linux/sunrpc/debug.h
- /usr/include/linux/tc_act/tc_gact.h
- /usr/include/linux/tc_act/tc_ipt.h
- /usr/include/linux/tc_act/tc_mirred.h
- /usr/include/linux/tc_act/tc_nat.h
- /usr/include/linux/tc_act/tc_pedit.h
- /usr/include/linux/tc_act/tc_skbedit.h
- /usr/include/linux/tc_ematch/tc_em_cmp.h
- /usr/include/linux/tc_ematch/tc_em_meta.h
- /usr/include/linux/tc_ematch/tc_em_nbyte.h
- /usr/include/linux/tc_ematch/tc_em_text.h
- /usr/include/linux/usb/audio.h
- /usr/include/linux/usb/cdc.h
- /usr/include/linux/usb/ch9.h
- /usr/include/linux/usb/g_printer.h
- /usr/include/linux/usb/gadgetfs.h
- /usr/include/linux/usb/midi.h
- /usr/include/linux/usb/tmc.h
- /usr/include/linux/usb/vstusb.h
- /usr/include/linux/wimax/i2400m.h
- /usr/include/mtd/inftl-user.h
- /usr/include/mtd/mtd-abi.h
- /usr/include/mtd/mtd-user.h
- /usr/include/mtd/nftl-user.h
- /usr/include/mtd/ubi-user.h
- /usr/include/rdma/ib_user_cm.h
- /usr/include/rdma/ib_user_mad.h
- /usr/include/rdma/ib_user_sa.h
- /usr/include/rdma/ib_user_verbs.h
- /usr/include/rdma/rdma_netlink.h
- /usr/include/rdma/rdma_user_cm.h
- /usr/include/sound/asequencer.h
- /usr/include/sound/asound.h
- /usr/include/sound/asound_fm.h
- /usr/include/sound/emu10k1.h
- /usr/include/sound/hdsp.h
- /usr/include/sound/hdspm.h
- /usr/include/sound/sb16_csp.h
- /usr/include/sound/sfnt_info.h
- /usr/include/sound/sscape_ioctl.h
- /usr/include/uapi/nvme.h
- /usr/include/video/edid.h
- /usr/include/video/sisfb.h
- /usr/include/video/uvesafb.h
- /usr/include/xen/evtchn.h







On Aineko, click the linked binary package file in the Download section of the package page on pkgs.org.




Transfer the binary rpm package file to Kalkin.


Package list:
- kernel-headers-2.6.32-696.el6.x86_64.rpm

kernel-headers-2.6.32-696.el6.x86_64.rpm provides:
- kernel-headers = 2.6.32-696.el6
- kernel-headers(x86-64) = 2.6.32-696.el6


Missing dependencies reported earlier when --test installing:
- kernel-headers
- kernel-headers >= 2.2.1








Next: Check the signature of the new rpm package.

[root@kalkin work]# rpm --checksig rpms/kernel-headers-2.6.32-696.el6.x86_64.rpm --verbose

rpms/kernel-headers-2.6.32-696.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: OK Header SHA1 digest: OK (b02b93e58dd2cdc6c420ff3cd956990724682118) V3 RSA/SHA1 Signature, key ID c105b9de: OK MD5 digest: OK (8f2cdf3e3611fc72eed2cf836496c32d)



Notes:
- All signatures are valid.
- Both signatures in all four packages have key ID == c105b9de (i.e. the Centos 6 signing key's key ID).



Next: Run a --test install for the new package. Note which dependencies, if any, are lacking on the system.



[root@kalkin work]# rpm --install rpms/kernel-headers-2.6.32-696.el6.x86_64.rpm --test




No new dependencies.




Next: Install the gcc rpm and the rpms that compose its dependency tree.


Excerpt from:
ftp.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html

As long as the requiring and the providing packages are installed using the same invocation of RPM, the dependency checking will succeed. For example, the command
rpm -ivh *.rpm
will properly check for dependencies, even if the requiring package ends up being installed before the providing package.




Excerpt from:
ftp.rpm.org/max-rpm/s1-rpm-install-handy-options.html

When performing installs, RPM is pretty quiet, unless something goes wrong. However, we can ask for a bit more output by adding
-v
to the command:

# rpm -iv eject-1.2-2.i386.rpm
Installing eject-1.2-2.i386.rpm
#


By adding
-v
, RPM displayed a simple status line. Using
-v
is a good idea, particularly if you're going to use a single command to install more than one package:

# rpm -iv *.rpm
Installing eject-1.2-2.i386.rpm
Installing iBCS-1.2-3.i386.rpm
Installing logrotate-1.0-1.i386.rpm
#


In this case, there were three .rpm files in the directory. By using a simple wildcard, it's as easy to install one package as it is to install one hundred!


-h: Perfect for the Impatient

Sometimes a package can be quite large. Other than watching the disk activity light flash, there's no assurance that RPM is working, and if it is, how far along it is. If you add
-h
, RPM will print fifty hash marks ("#") as the install proceeds:

# rpm -ih eject-1.2-2.i386.rpm
##################################################
#


Once all fifty hash marks are printed, the package is completely installed. Using
-v
with
-h
results in a very nice display, particularly when installing more than one package:

# rpm -ivh *.rpm eject ################################################## iBCS ################################################## logrotate ################################################## #





Ok. I'll use
rpm -iv
, or rather
rpm --install --verbose
.


I'll do a test install, then an actual install.


[root@kalkin work]# cd rpms


[root@kalkin rpms]# ls -1

cloog-ppl-0.15.7-1.2.el6.x86_64.rpm
cpp-4.4.7-18.el6.x86_64.rpm
gcc-4.4.7-18.el6.x86_64.rpm
glibc-devel-2.12-1.209.el6.x86_64.rpm
glibc-headers-2.12-1.209.el6.x86_64.rpm
kernel-headers-2.6.32-696.el6.x86_64.rpm
libgomp-4.4.7-18.el6.x86_64.rpm
mpfr-2.4.1-6.el6.x86_64.rpm
ppl-0.10.2-11.el6.x86_64.rpm

[root@kalkin rpms]# rpm --install gcc-4.4.7-18.el6.x86_64.rpm cloog-ppl-0.15.7-1.2.el6.x86_64.rpm cpp-4.4.7-18.el6.x86_64.rpm glibc-devel-2.12-1.209.el6.x86_64.rpm glibc-headers-2.12-1.209.el6.x86_64.rpm kernel-headers-2.6.32-696.el6.x86_64.rpm libgomp-4.4.7-18.el6.x86_64.rpm mpfr-2.4.1-6.el6.x86_64.rpm ppl-0.10.2-11.el6.x86_64.rpm --test


[root@kalkin rpms]# rpm --install gcc-4.4.7-18.el6.x86_64.rpm cloog-ppl-0.15.7-1.2.el6.x86_64.rpm cpp-4.4.7-18.el6.x86_64.rpm glibc-devel-2.12-1.209.el6.x86_64.rpm glibc-headers-2.12-1.209.el6.x86_64.rpm kernel-headers-2.6.32-696.el6.x86_64.rpm libgomp-4.4.7-18.el6.x86_64.rpm mpfr-2.4.1-6.el6.x86_64.rpm ppl-0.10.2-11.el6.x86_64.rpm --test --verbose

Preparing packages for installation...

[root@kalkin rpms]# rpm --install gcc-4.4.7-18.el6.x86_64.rpm cloog-ppl-0.15.7-1.2.el6.x86_64.rpm cpp-4.4.7-18.el6.x86_64.rpm glibc-devel-2.12-1.209.el6.x86_64.rpm glibc-headers-2.12-1.209.el6.x86_64.rpm kernel-headers-2.6.32-696.el6.x86_64.rpm libgomp-4.4.7-18.el6.x86_64.rpm mpfr-2.4.1-6.el6.x86_64.rpm ppl-0.10.2-11.el6.x86_64.rpm --verbose

Preparing packages for installation...
ppl-0.10.2-11.el6
cloog-ppl-0.15.7-1.2.el6
mpfr-2.4.1-6.el6
cpp-4.4.7-18.el6
libgomp-4.4.7-18.el6
kernel-headers-2.6.32-696.el6
glibc-headers-2.12-1.209.el6
glibc-devel-2.12-1.209.el6
gcc-4.4.7-18.el6

[root@kalkin rpms]# rpm --query --all | wc -l

215



Hm.

The installation appears to have been successful.


Earlier, there were 205 packages.

This list has only 9 items:
- ppl-0.10.2-11.el6
- cloog-ppl-0.15.7-1.2.el6
- mpfr-2.4.1-6.el6
- cpp-4.4.7-18.el6
- libgomp-4.4.7-18.el6
- kernel-headers-2.6.32-696.el6
- glibc-headers-2.12-1.209.el6
- glibc-devel-2.12-1.209.el6
- gcc-4.4.7-18.el6

Why is there an extra package?



Here is the new package list.

[root@kalkin rpms]# rpm --query --all | sort

acl-2.2.49-7.el6.x86_64
attr-2.4.44-7.el6.x86_64
audit-2.4.5-6.el6.x86_64
audit-libs-2.4.5-6.el6.x86_64
authconfig-6.1.12-23.el6.x86_64
b43-openfwwf-5.2-10.el6.noarch
basesystem-10.0-4.el6.noarch
bash-4.1.2-48.el6.x86_64
binutils-2.20.51.0.2-5.46.el6.x86_64
bridge-utils-1.2-10.el6.x86_64
bzip2-1.0.5-7.el6_0.x86_64
bzip2-libs-1.0.5-7.el6_0.x86_64
ca-certificates-2016.2.10-65.4.el6.noarch
centos-release-6-9.el6.12.3.x86_64
checkpolicy-2.0.22-1.el6.x86_64
chkconfig-1.3.49.5-1.el6.x86_64
cloog-ppl-0.15.7-1.2.el6.x86_64
coreutils-8.4-46.el6.x86_64
coreutils-libs-8.4-46.el6.x86_64
cpio-2.10-13.el6.x86_64
cpp-4.4.7-18.el6.x86_64
cracklib-2.8.16-4.el6.x86_64
cracklib-dicts-2.8.16-4.el6.x86_64
cronie-1.4.4-16.el6_8.2.x86_64
cronie-anacron-1.4.4-16.el6_8.2.x86_64
crontabs-1.10-33.el6.noarch
cryptsetup-luks-1.2.0-11.el6.x86_64
cryptsetup-luks-libs-1.2.0-11.el6.x86_64
curl-7.19.7-52.el6.x86_64
cyrus-sasl-2.1.23-15.el6_6.2.x86_64
cyrus-sasl-lib-2.1.23-15.el6_6.2.x86_64
dash-0.5.5.1-4.el6.x86_64
db4-4.7.25-22.el6.x86_64
db4-utils-4.7.25-22.el6.x86_64
dbus-glib-0.86-6.el6.x86_64
dbus-libs-1.2.24-8.el6_6.x86_64
device-mapper-1.02.117-12.el6.x86_64
device-mapper-event-1.02.117-12.el6.x86_64
device-mapper-event-libs-1.02.117-12.el6.x86_64
device-mapper-libs-1.02.117-12.el6.x86_64
device-mapper-multipath-0.4.9-100.el6.x86_64
device-mapper-multipath-libs-0.4.9-100.el6.x86_64
device-mapper-persistent-data-0.6.2-0.1.rc7.el6.x86_64
dhclient-4.1.1-53.P1.el6.centos.x86_64
dhcp-common-4.1.1-53.P1.el6.centos.x86_64
diffutils-2.8.1-28.el6.x86_64
dracut-004-409.el6_8.2.noarch
dracut-kernel-004-409.el6_8.2.noarch
e2fsprogs-1.41.12-23.el6.x86_64
e2fsprogs-libs-1.41.12-23.el6.x86_64
efibootmgr-0.5.4-15.el6.x86_64
elfutils-libelf-0.164-2.el6.x86_64
ethtool-3.5-6.el6.x86_64
expat-2.0.1-13.el6_8.x86_64
file-5.04-30.el6.x86_64
file-libs-5.04-30.el6.x86_64
filesystem-2.4.30-3.el6.x86_64
findutils-4.4.2-9.el6.x86_64
fipscheck-1.2.0-7.el6.x86_64
fipscheck-lib-1.2.0-7.el6.x86_64
fuse-2.8.3-5.el6.x86_64
gamin-0.1.10-9.el6.x86_64
gawk-3.1.7-10.el6_7.3.x86_64
gcc-4.4.7-18.el6.x86_64
gdbm-1.8.0-39.el6.x86_64
glib2-2.28.8-9.el6.x86_64
glibc-2.12-1.209.el6.x86_64
glibc-common-2.12-1.209.el6.x86_64
glibc-devel-2.12-1.209.el6.x86_64
glibc-headers-2.12-1.209.el6.x86_64
gmp-4.3.1-12.el6.x86_64
gnupg2-2.0.14-8.el6.x86_64
gpgme-1.1.8-3.el6.x86_64
gpg-pubkey-c105b9de-4e0fd3a3
grep-2.20-6.el6.x86_64
groff-1.18.1.4-21.el6.x86_64
grub-0.97-99.el6.x86_64
grubby-7.0.15-7.el6.x86_64
gzip-1.3.12-24.el6.x86_64
hwdata-0.233-18.1.el6.noarch
info-4.13a-8.el6.x86_64
initscripts-9.03.58-1.el6.centos.x86_64
iproute-2.6.32-54.el6.x86_64
iptables-1.4.7-16.el6.x86_64
iptables-ipv6-1.4.7-16.el6.x86_64
iputils-20071127-24.el6.x86_64
iscsi-initiator-utils-6.2.0.873-26.el6.x86_64
kbd-1.15-11.el6.x86_64
kbd-misc-1.15-11.el6.noarch
kernel-2.6.32-696.el6.x86_64
kernel-firmware-2.6.32-696.el6.noarch
kernel-headers-2.6.32-696.el6.x86_64
keyutils-libs-1.4-5.el6.x86_64
kpartx-0.4.9-100.el6.x86_64
krb5-libs-1.10.3-65.el6.x86_64
less-436-13.el6.x86_64
libacl-2.2.49-7.el6.x86_64
libaio-0.3.107-10.el6.x86_64
libattr-2.4.44-7.el6.x86_64
libblkid-2.17.2-12.28.el6.x86_64
libcap-2.16-5.5.el6.x86_64
libcap-ng-0.6.4-3.el6_0.1.x86_64
libcom_err-1.41.12-23.el6.x86_64
libcurl-7.19.7-52.el6.x86_64
libdrm-2.4.65-2.el6.x86_64
libedit-2.11-4.20080712cvs.1.el6.x86_64
libffi-3.0.5-3.2.el6.x86_64
libgcc-4.4.7-18.el6.x86_64
libgcrypt-1.4.5-12.el6_8.x86_64
libgomp-4.4.7-18.el6.x86_64
libgpg-error-1.7-4.el6.x86_64
libidn-1.18-2.el6.x86_64
libnih-1.0.1-7.el6.x86_64
libpciaccess-0.13.4-1.el6.x86_64
libselinux-2.0.94-7.el6.x86_64
libselinux-utils-2.0.94-7.el6.x86_64
libsemanage-2.0.43-5.1.el6.x86_64
libsepol-2.0.41-4.el6.x86_64
libss-1.41.12-23.el6.x86_64
libssh2-1.4.2-2.el6_7.1.x86_64
libstdc++-4.4.7-18.el6.x86_64
libtasn1-2.3-6.el6_5.x86_64
libudev-147-2.73.el6_8.2.x86_64
libusb-0.1.12-23.el6.x86_64
libuser-0.56.13-8.el6_7.x86_64
libutempter-1.1.5-4.1.el6.x86_64
libuuid-2.17.2-12.28.el6.x86_64
libxml2-2.7.6-21.el6_8.1.x86_64
logrotate-3.7.8-28.el6.x86_64
lua-5.1.4-4.1.el6.x86_64
lvm2-2.02.143-12.el6.x86_64
lvm2-libs-2.02.143-12.el6.x86_64
m4-1.4.13-5.el6.x86_64
make-3.81-23.el6.x86_64
MAKEDEV-3.24-6.el6.x86_64
mdadm-3.3.4-8.el6.x86_64
mingetty-1.08-5.el6.x86_64
module-init-tools-3.9-26.el6.x86_64
mpfr-2.4.1-6.el6.x86_64
mysql-libs-5.1.73-8.el6_8.x86_64
ncurses-5.7-4.20090207.el6.x86_64
ncurses-base-5.7-4.20090207.el6.x86_64
ncurses-libs-5.7-4.20090207.el6.x86_64
net-tools-1.60-114.el6.x86_64
newt-0.52.11-4.el6.x86_64
newt-python-0.52.11-4.el6.x86_64
nspr-4.13.1-1.el6.x86_64
nss-3.27.1-13.el6.x86_64
nss-softokn-3.14.3-23.3.el6_8.x86_64
nss-softokn-freebl-3.14.3-23.3.el6_8.x86_64
nss-sysinit-3.27.1-13.el6.x86_64
nss-tools-3.27.1-13.el6.x86_64
nss-util-3.27.1-3.el6.x86_64
openldap-2.4.40-16.el6.x86_64
openssh-5.3p1-122.el6.x86_64
openssh-clients-5.3p1-122.el6.x86_64
openssh-server-5.3p1-122.el6.x86_64
openssl-1.0.1e-57.el6.x86_64
p11-kit-0.18.5-2.el6_5.2.x86_64
p11-kit-trust-0.18.5-2.el6_5.2.x86_64
pam-1.1.1-24.el6.x86_64
passwd-0.77-7.el6.x86_64
pciutils-libs-3.1.10-4.el6.x86_64
pcre-7.8-7.el6.x86_64
pinentry-0.7.6-8.el6.x86_64
pkgconfig-0.23-9.1.el6.x86_64
plymouth-0.8.3-29.el6.centos.x86_64
plymouth-core-libs-0.8.3-29.el6.centos.x86_64
plymouth-scripts-0.8.3-29.el6.centos.x86_64
policycoreutils-2.0.83-30.1.el6_8.x86_64
popt-1.13-7.el6.x86_64
postfix-2.6.6-8.el6.x86_64
ppl-0.10.2-11.el6.x86_64
procps-3.2.8-45.el6.x86_64
psmisc-22.6-24.el6.x86_64
pth-2.0.7-9.3.el6.x86_64
pygpgme-0.1-18.20090824bzr68.el6.x86_64
python-2.6.6-66.el6_8.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
python-libs-2.6.6-66.el6_8.x86_64
python-pycurl-7.19.0-9.el6.x86_64
python-urlgrabber-3.9.1-11.el6.noarch
readline-6.0-4.el6.x86_64
redhat-logos-60.0.14-12.el6.centos.noarch
rootfiles-8.1-6.1.el6.noarch
rpm-4.8.0-55.el6.x86_64
rpm-libs-4.8.0-55.el6.x86_64
rpm-python-4.8.0-55.el6.x86_64
rsyslog-5.8.10-10.el6_6.x86_64
sed-4.2.1-10.el6.x86_64
selinux-policy-3.7.19-307.el6.noarch
selinux-policy-targeted-3.7.19-307.el6.noarch
setup-2.8.14-23.el6.noarch
shadow-utils-4.1.5.1-5.el6.x86_64
shared-mime-info-0.70-6.el6.x86_64
slang-2.2.1-1.el6.x86_64
sqlite-3.6.20-1.el6_7.2.x86_64
sudo-1.8.6p3-27.el6.x86_64
system-config-firewall-base-1.2.27-7.2.el6_6.noarch
sysvinit-tools-2.87-6.dsf.el6.x86_64
tar-1.23-15.el6_8.x86_64
tcp_wrappers-libs-7.6-58.el6.x86_64
tzdata-2016j-1.el6.noarch
udev-147-2.73.el6_8.2.x86_64
upstart-0.6.5-16.el6.x86_64
ustr-1.0.4-9.1.el6.x86_64
util-linux-ng-2.17.2-12.28.el6.x86_64
vim-minimal-7.4.629-5.el6_8.1.x86_64
which-2.19-6.el6.x86_64
xfsprogs-3.1.1-20.el6.x86_64
xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64
yum-3.2.29-81.el6.centos.noarch
yum-metadata-parser-1.1.2-16.el6.x86_64
yum-plugin-fastestmirror-1.1.30-40.el6.noarch
zlib-1.2.3-29.el6.x86_64





On Aineko, save this list as list_new.txt.

Save the old list of available packages as list_old.txt.

aineko:Downloads stjohnpiano$ diff list_old.txt list_new.txt

16a17
> cloog-ppl-0.15.7-1.2.el6.x86_64
19a21
> cpp-4.4.7-18.el6.x86_64
61a64
> gcc-4.4.7-18.el6.x86_64
65a69,70
> glibc-devel-2.12-1.209.el6.x86_64
> glibc-headers-2.12-1.209.el6.x86_64
68a74
> gpg-pubkey-c105b9de-4e0fd3a3
85a92
> kernel-headers-2.6.32-696.el6.x86_64
102a110
> libgomp-4.4.7-18.el6.x86_64
130a139
> mpfr-2.4.1-6.el6.x86_64
163a173
> ppl-0.10.2-11.el6.x86_64




Aha. The extra package is gpg-pubkey-c105b9de-4e0fd3a3, i.e. the package resulting from the import of the Centos 6 signing key.






Right. Let's test the gcc compiler.



[root@kalkin rpms]# cd work


[root@kalkin work]# gcc --version

gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[root@kalkin work]# gcc --help

Usage: gcc [options] file... Options: -pass-exit-codes Exit with highest error code from a phase --help Display this information --target-help Display target specific command line options --help={target|optimizers|warnings|params|[^]{joined|separate|undocumented}}[,...] Display specific types of command line options (Use '-v --help' to display command line options of sub-processes) --version Display compiler version information -dumpspecs Display all of the built in spec strings -dumpversion Display the version of the compiler -dumpmachine Display the compiler's target processor -print-search-dirs Display the directories in the compiler's search path -print-libgcc-file-name Display the name of the compiler's companion library -print-file-name=<lib> Display the full path to library <lib> -print-prog-name=<prog> Display the full path to compiler component <prog> -print-multi-directory Display the root directory for versions of libgcc -print-multi-lib Display the mapping between command line options and multiple library search directories -print-multi-os-directory Display the relative path to OS libraries -print-sysroot Display the target libraries directory -print-sysroot-headers-suffix Display the sysroot suffix used to find headers -Wa,<options> Pass comma-separated <options> on to the assembler -Wp,<options> Pass comma-separated <options> on to the preprocessor -Wl,<options> Pass comma-separated <options> on to the linker -Xassembler <arg> Pass <arg> on to the assembler -Xpreprocessor <arg> Pass <arg> on to the preprocessor -Xlinker <arg> Pass <arg> on to the linker -combine Pass multiple source files to compiler at once -save-temps Do not delete intermediate files -pipe Use pipes rather than intermediate files -time Time the execution of each subprocess -specs=<file> Override built-in specs with the contents of <file> -std=<standard> Assume that the input sources are for <standard> --sysroot=<directory> Use <directory> as the root directory for headers and libraries -B <directory> Add <directory> to the compiler's search paths -b <machine> Run gcc for target <machine>, if installed -V <version> Run gcc version number <version>, if installed -v Display the programs invoked by the compiler -### Like -v but options quoted and commands not executed -E Preprocess only; do not compile, assemble or link -S Compile only; do not assemble or link -c Compile and assemble, but do not link -o <file> Place the output into <file> -x <language> Specify the language of the following input files Permissible languages include: c c++ assembler none 'none' means revert to the default behavior of guessing the language based on the file's extension Options starting with -g, -f, -m, -O, -W, or --param are automatically passed on to the various sub-processes invoked by gcc. In order to pass other options on to these processes the -W<letter> options must be used. For bug reporting instructions, please see: <http://bugzilla.redhat.com/bugzilla>.








On Kalkin, using vi, create a new file, write the following code into it, and save it as
hello_world.c
.

Hello World in C

c

[download this code]
/* Hello World in C */
#include <stdio.h>

int main(void)
{
	printf("Hello World\n");
	return 0;
}




[root@kalkin work]# ls -1

archived
hello_world.c
rpms
tmp

[root@kalkin work]# gcc hello_world.c


[root@kalkin work]# ls -1

a.out
archived
hello_world.c
rpms
tmp

[root@kalkin work]# ./a.out

Hello World

[root@kalkin work]# gcc -o hello_world hello_world.c


[root@kalkin work]# ls -1

a.out
archived
hello_world
hello_world.c
rpms
tmp

[root@kalkin work]# ./hello_world

Hello World

[root@kalkin work]# rm -f a.out


[root@kalkin work]# mv hello* archived/


[root@kalkin work]# ls -1

archived
rpms
tmp

[root@kalkin work]# ls -1 archived

bible.txt
hello.txt
hello_world
hello_world.c

[root@kalkin work]# ./archived/hello_world

Hello World




Excellent.










I'd like to know a bit more about how rpm handles config files.


Excerpt from:
ftp.rpm.org/max-rpm/ch-rpm-install.html

Chapter 2. Using RPM to Install Packages


Of the many things RPM can do, probably the one that people think of first is the installation of software. As mentioned earlier, installing new software is a complex, error-prone job. RPM turns that process into a single command.

rpm -i
(
--install
is equivalent) installs software that's been packaged into an RPM package file. It does this by:

- Performing dependency checks.

- Checking for conflicts.

- Performing any tasks required before the install.

- Deciding what to do with config files.

- Unpacking files from the package and putting them in the proper place.

- Performing any tasks required after the install.

- Keeping track of what it did.


Let's go through each of these steps in a bit more detail.


Performing dependency checks:

Some packages will not operate properly unless some other package is installed, too. RPM makes sure that the package being installed will have its dependency requirements met. It will also insure that the package's installation will not cause dependency problems for other already-installed packages.


Checking for conflicts:

RPM performs a number of checks during this phase. These checks look for things like attempts to install an already installed package, attempts to install an older package over a newer version, or the possibility that a file may be overwritten.


Performing any tasks required before the install:

There are cases where one or more commands must be given prior to the actual installation of a package. RPM performs these commands exactly as directed by the package builder, thus eliminating a common source of problems during installations.


Deciding what to do with config files:

One of the features that really sets RPM apart from other package managers, is the way it handles configuration files. Since these files are normally changed to customize the behavior of installed software, simply overwriting a config file would tend to make people angry - all their customizations would be gone! Instead, RPM analyzes the situation and attempts to do "the right thing" with config files, even if they weren't originally installed by RPM! [*]

[*] Are you interested in what exactly "the right thing" means? the Section called Config file magic in Chapter 4 has all the details.


Unpacking files from the package and putting them in the proper place:

This is the step most people think of when they think about installing software. Each package file contains a list of files that are to be installed, as well as their destination on your system. In addition, many other file attributes, such as permissions and ownerships, are set correctly by RPM.


Performing any tasks required after the install:

Very often a new package requires that one or more commands be executed after the new files are in place. An example of this would be running
ldconfig
to make new shared libraries accessible.


Keeping track of what it did:

Every time RPM installs a package on your system, it keeps track of the files it installed, in its database. The database contains a wealth of information necessary for RPM to do its job. For example, RPM uses the database when it checks for possible conflicts during an install.



Hm. Interesting.


"RPM analyzes the situation and attempts to do "the right thing" with config files, even if they weren't originally installed by RPM"


Excerpt from:
ftp.rpm.org/max-rpm/ch-rpm-upgrade.html#S2-RPM-UPGRADE-CONFIG-FILE-MAGIC

Chapter 4. Using RPM to Upgrade Packages


There are no less than six different scenarios that RPM takes into account when handling config files.

In order to make the appropriate decisions, RPM needs information. The information used to decide how to handle config files is a set of three large numbers known as MD5 checksums. An MD5 checksum is produced when a file is used as the input to a complex series of mathematical operations. The resulting checksum has a unique property, in that any change to the file's contents will result in a change to the checksum of that file. [*] Therefore, MD5 checksums are a powerful tool for quickly determining whether two different files have the same contents or not.

[*] Actually, there's a one in 2^128 chance a change will go undetected, but for all practical purposes, it's as close to perfect as we can get.

In the previous paragraph, we stated that RPM uses three different MD5 checksums to determine what should be done with a config file. The three checksums are:

- The MD5 checksum of the file when it was originally installed. We'll call this the original file.

- The MD5 checksum of the file as it exists at upgrade time. We'll call this the current file.

- The MD5 checksum of the corresponding file in the new package. We'll call this the new file.

Let's take a look at the various combinations of checksums, see what RPM will do because of them, and discuss why. In the following examples, we'll use the letters X, Y, and Z in place of lengthy MD5 checksums.


1) Original file = X, Current file = X, New file = X

In this case, the file originally installed was never modified. [*] The file in the new version of the package is identical to the file on disk.

[*] Or, as some sticklers for detail may note, it may have been modified, and subsequently those modifications were undone.

In this case, RPM installs the new file, overwriting the original. You may be wondering why go to the trouble of installing the new file if it's just the same as the existing one. The reason is that aspects of the file other than its name and contents might have changed. The file's ownership, for example, might be different in the new version.


2) Original file = X, Current file = X, New file = Y

The original file has not been modified, but the file in the new package is different. Perhaps the difference represents a bug-fix, or a new feature. It makes no difference to RPM.

In this case, RPM installs the new file, overwriting the original. This makes sense. If it didn't, RPM would never permit newer, modified versions of software to be installed! The original file is not saved, since it had not been changed. A lack of changes here means that no site-specific modifications were made to the file.


3) Original file = X, Current file = Y, New file = X

Here we have a file that was changed at some point. However, the new file is identical to the existing file prior to the local modifications.

In this case, RPM takes the viewpoint that since the original file and the new file are identical, the modifications made to the original version must still be valid for the new version. It leaves the existing, modified file in place.


4) Original file = X, Current file = Y, New file = Y

At some point the original file was modified, and those modifications happen to make the file identical to the new file. Perhaps the modification was made to fix a security problem, and the new version of the file has the same fix applied to it.

In this case, RPM installs the new version, overwriting the modified original. The same philosophy used in the first scenario applies here - although the file has not changed, perhaps some other aspect of the file has, so the new version is installed.


5) Original file = X, Current file = Y, New file = Z

Here the original file was modified at some point. The new file is different from both the original and the modified versions of the original file.

RPM is not able to analyze the contents of the files, and determine what is going on. In this instance, it takes the best possible approach. The new file is known to work properly with the rest of the software in the new package - at least the people building the new package should have insured that it does. The modified original file is an unknown: it might work with the new package, it might not. So RPM installs the new file.

BUT... The existing file was definitely modified. Someone made an effort to change the file, for some reason. Perhaps the information contained in the file is still of use. Therefore, RPM saves the modified file, naming it
[file].rpmsave
, and prints a warning, so the user knows what happened:

warning: /etc/skel/.bashrc saved as /etc/skel/.bashrc.rpmsave


These five scenarios cover just about every possible circumstance, save one. The missing scenario?


6) Original file = none, Current file = ??, New file = ??

While RPM doesn't use checksums in this particular case, we'll describe it in those terms, for the sake of consistency. In this instance, RPM had not installed the file originally, so there is no original checksum.

Because the file had not originally been installed as part of a package, there is no way for RPM to determine if the file currently in place had been modified. Therefore, the checksums for the current file and the new file are irrelevant; they cannot be used to clear up the mystery.

When this happens, RPM renames the file to
[file].rpmorig
, prints a warning, and installs the new file. This way, any modifications contained in the original file are saved. The system administrator can review the differences between the original and the newly installed files and determine what action should be taken.

As you can see, in the majority of cases RPM will automatically take the proper course of action when performing an upgrade. It is only when config files have been modified and are to be overwritten, that RPM leaves any post-upgrade work for the system administrator. Even in those cases, many times the modified files are not worth saving and can be deleted.



Notes:
- In case 3, rpm assumes that the modifications to the config file will still be valid for the new version of the software. It's a good bet, since if the new config file is not different to the original config file, the new version probably won't have changed drastically. However, it's worth noting that it might have changed in such a way that some of the config modifications won't be compatible and will cause problems.
- In case 5, rpm assumes that the modifications to the config file will NOT still be valid for the new version of the software. It's a good bet, since the new config file is different to the original config file. It's possible, but not likely, that the modifications will still be compatible with the new version of the software.
- I note that in case 3, rpm does not call for human intervention, but it does in case 5. Occasionally, human intervention might be required in case 3.




How does rpm know which files are config files?


Earlier, when examining the output of
rpm --dump
, I found that each file in a package's file list had an "ifconfig" flag.

isconfig = 0 = is this file a configuration file? 0 is "false". Therefore this file does not appear in the rpm output when the --configfiles flag is used.


So a package will contain a declaration that a particular file is a config file.



Excerpts from:
ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html

Chapter 13. Inside the Spec File


The %files list may contain a number of different directives. They are used to:

- Identify documentation and configuration files.

- Ensure that a file has the correct permissions and ownership set.

- Control which aspects of a file are to be checked during package verification.

[...]

The
%config
directive is used to flag the specified file as being a configuration file. RPM performs additional processing for config files when packages are erased, and during installations and upgrades. This is due to the nature of config files: They are often changed by the system administrator, and those changes should not be lost.




A slight additional problem with config files:


Excerpt from:
people.ds.cam.ac.uk/jw35/docs/rpm_config.html
Author: Jon Warbrick

I don't know what happens if RPM needs to create an
.rpmsave
or
.rpmnew
file and one already exists - at least in some cases it seems that the new file isn't written under these circumstances.




Excerpts from:
ftp.rpm.org/max-rpm/s1-rpm-install-additional-options.html

Chapter 2. Using RPM to Install Packages

[...]

While the
--replacepkgs
option permitted a package to be installed "on top of" itself,
--replacefiles
is used to allow a package to overwrite files belonging to a different package.

[...]

File conflicts should be a relatively rare occurrence. They only happen when two packages attempt to install files with the same name but different contents. There are two possible reasons for this to happen:

- Installing a newer version of a package without erasing the older version. A newer version of a package is a wonderful source of file conflicts against older versions - the filenames remain the same, but the contents change. We used it in our example because it's an easy way to show what happens when there are file conflicts. However, it is usually a bad idea when it comes to doing this as a way to upgrade packages. RPM has a special option for this (
rpm -U
) that is discussed in Chapter 4.

- Installing two unrelated packages that each install a file with the same name. This may happen because of poor package design (hence the file residing in more than one package), or a lack of coordination between the people building the packages.

[...]

What happens if a conflicting file is a config file that you've sweated over and worked on until it's just right? Will issuing a
--replacefiles
on a package with a conflicting config file blow all your changes away?

No! RPM won't cook your goose.

It will save any changes you've made, to a config file called
[file].rpmsave
.






Some thoughts:
- Many software items will eventually need a way to store their settings. The simplest method of storing settings is a text file in a particular format i.e. a configuration file. A new version of a software item may have different default settings or use a new format for its configuration file(s).
- Package managers need to handle the changing state and format of the config file(s) of each software item.
- Package managers have to handle the different versions and config files of software items that are targeted at several CPU architectures.
- Harder problem: A package manager that handles new formats for its packages, public keys, and digital signatures.
- Even harder problem: A package manager that handles the changing code, state, and config file format of its own self.
- A package manager is a formalised way of moving software items onto a computer system. Software items are big ugly heaps of state. Software items are prone to try to interfere with one another's state.
- A software item's state can be thought of as its territory within the environment of the computer system's filesystem. rpm is a manager that tries to stop software items from seizing each other's territory.
- A package is a large patch on the state of a computer system.
-- For this patching to work consistently, a section of the computer system should be designated as the territory of the package manager. The user should not interfere with this territory, and should only make changes to it by issuing commands to the package manager. Exception: user edits to config files.












Next: Write the dependency tree that I needed to build on Kalkin for installing the gcc rpm package.


First, compile a short history:


START HISTORY

I downloaded gcc-4.4.7-18.el6.x86_64.rpm from
mirror.centos.org/centos/6/os/x86_64/Packages

gcc-4.4.7-18.el6.x86_64.rpm
requires these dependencies (found via running
rpm --requires
):
- /bin/sh
- /sbin/install-info
- binutils >= 2.19.51.0.14-33
- cloog-ppl >= 0.15
- cpp = 4.4.7-18.el6
- glibc-devel >= 2.2.90-12
- libc.so.6()(64bit)
- libc.so.6(GLIBC_2.11)(64bit)
- libc.so.6(GLIBC_2.2.5)(64bit)
- libc.so.6(GLIBC_2.3)(64bit)
- libc.so.6(GLIBC_2.4)(64bit)
- libc.so.6(GLIBC_2.7)(64bit)
- libgcc >= 4.4.7-18.el6
- libgcc_s.so.1()(64bit)
- libgomp = 4.4.7-18.el6
- libgomp.so.1()(64bit)
- rpmlib(CompressedFileNames) <= 3.0.4-1
- rpmlib(FileDigests) <= 4.6.0-1
- rpmlib(PartialHardlinkSets) <= 4.0.4-1
- rpmlib(PayloadFilesHavePrefix) <= 4.0-1
- rpmlib(VersionedDependencies) <= 3.0.3-1
- rtld(GNU_HASH)
- rpmlib(PayloadIsXz) <= 5.2-1

These dependencies were missing (found via running
rpm --install --test
):
- cloog-ppl >= 0.15
- cpp = 4.4.7-18.el6
- glibc-devel >= 2.2.90-12
- libgomp = 4.4.7-18.el6
- libgomp.so.1()(64bit)

From which I deduce that these dependencies were included in Centos 6.9 Minimal:
- /bin/sh
- /sbin/install-info
- binutils >= 2.19.51.0.14-33
- libc.so.6()(64bit)
- libc.so.6(GLIBC_2.11)(64bit)
- libc.so.6(GLIBC_2.2.5)(64bit)
- libc.so.6(GLIBC_2.3)(64bit)
- libc.so.6(GLIBC_2.4)(64bit)
- libc.so.6(GLIBC_2.7)(64bit)
- libgcc >= 4.4.7-18.el6
- libgcc_s.so.1()(64bit)
- rpmlib(CompressedFileNames) <= 3.0.4-1
- rpmlib(FileDigests) <= 4.6.0-1
- rpmlib(PartialHardlinkSets) <= 4.0.4-1
- rpmlib(PayloadFilesHavePrefix) <= 4.0-1
- rpmlib(VersionedDependencies) <= 3.0.3-1
- rtld(GNU_HASH)
- rpmlib(PayloadIsXz) <= 5.2-1

I searched on:
pkgs.org
for each of the missing dependencies and selected a package from the search results.
Names of selected packages (with fulfilled dependencies in parentheses):
- cloog-ppl-0.15.7-1.2.el6.x86_64.rpm (cloog-ppl >= 0.15)
- cpp-4.4.7-18.el6.x86_64.rpm (cpp = 4.4.7-18.el6)
- glibc-devel-2.12-1.209.el6.x86_64.rpm (glibc-devel >= 2.2.90-12)
- libgomp-4.4.7-18.el6.x86_64.rpm (libgomp = 4.4.7-18.el6, libgomp.so.1()(64bit))


Here are the lists of missing dependencies for each new package (found via running
rpm --install --test
):

cloog-ppl-0.15.7-1.2.el6.x86_64.rpm was missing these dependencies:
- libppl.so.7()(64bit)
- libppl_c.so.2()(64bit)

cpp-4.4.7-18.el6.x86_64.rpm was missing these dependencies:
- libmpfr.so.1()(64bit)

glibc-devel-2.12-1.209.el6.x86_64.rpm was missing these dependencies:
- glibc-headers
- glibc-headers = 2.12-1.209.el6

libgomp-4.4.7-18.el6.x86_64.rpm was not missing any dependencies.

I searched on:
pkgs.org
for each of the missing dependencies and selected a package from the search results.
Names of selected packages (with fulfilled dependencies in parentheses):
- ppl-0.10.2-11.el6.x86_64.rpm (libppl.so.7()(64bit), libppl_c.so.2()(64bit))
- mpfr-2.4.1-6.el6.x86_64.rpm (libmpfr.so.1()(64bit))
- glibc-headers-2.12-1.209.el6.x86_64.rpm (glibc-headers, glibc-headers = 2.12-1.209.el6)


Here are the lists of missing dependencies for each new package (found via running
rpm --install --test
):

glibc-headers-2.12-1.209.el6.x86_64.rpm was missing these dependencies:
- kernel-headers
- kernel-headers >= 2.2.1

mpfr-2.4.1-6.el6.x86_64.rpm was not missing any dependencies.

ppl-0.10.2-11.el6.x86_64.rpm was not missing any dependencies.

I searched on:
pkgs.org
for each of the missing dependencies and selected a package from the search results.
Names of selected packages (with fulfilled dependencies in parentheses):
- kernel-headers-2.6.32-696.el6.x86_64.rpm (kernel-headers, kernel-headers >= 2.2.1)


Here are the lists of missing dependencies for each new package (found via running
rpm --install --test
):

kernel-headers-2.6.32-696.el6.x86_64.rpm was not missing any dependencies.

END HISTORY



Dependency Tree:

Base dependency: The operating system image
- centos-6.9-x86_64-minimal.iso

Goal: The gcc compiler package
- gcc-4.4.7-18.el6.x86_64.rpm

Tree of missing dependencies:
- gcc-4.4.7-18.el6.x86_64.rpm
-- cloog-ppl-0.15.7-1.2.el6.x86_64.rpm
--- ppl-0.10.2-11.el6.x86_64.rpm
-- cpp-4.4.7-18.el6.x86_64.rpm
--- mpfr-2.4.1-6.el6.x86_64.rpm
-- glibc-devel-2.12-1.209.el6.x86_64.rpm
--- glibc-headers-2.12-1.209.el6.x86_64.rpm
---- kernel-headers-2.6.32-696.el6.x86_64.rpm
-- libgomp-4.4.7-18.el6.x86_64.rpm



Dependency Tree in recursive list format:

Base: centos-6.9-x86_64-minimal.iso

Level 1:

gcc-4.4.7-18.el6.x86_64.rpm requires:
- cloog-ppl-0.15.7-1.2.el6.x86_64.rpm
- cpp-4.4.7-18.el6.x86_64.rpm
- glibc-devel-2.12-1.209.el6.x86_64.rpm
- libgomp-4.4.7-18.el6.x86_64.rpm

Level 2:

cloog-ppl-0.15.7-1.2.el6.x86_64.rpm requires:
- ppl-0.10.2-11.el6.x86_64.rpm

cpp-4.4.7-18.el6.x86_64.rpm requires:
- mpfr-2.4.1-6.el6.x86_64.rpm

glibc-devel-2.12-1.209.el6.x86_64.rpm requires:
- glibc-headers-2.12-1.209.el6.x86_64.rpm

Level 3:

glibc-headers-2.12-1.209.el6.x86_64.rpm requires:
- kernel-headers-2.6.32-696.el6.x86_64.rpm






Finished.







[start of notes]



Changes from the original text:

- I have not always preserved the format of any excerpts from webpages on other sites (e.g. not preserving the original bold/italic styles, changing the list structures, not preserving hyperlinks).

- I have not always preserved the format of any computer output (e.g. from running bash commands). Examples: Setting input lines in bold text, adding/removing newlines in order to make a sequence of commands easier to read, using hyphens for lists and sublists instead of indentation, breaking wide tables into consecutive sections.


[end of notes]