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








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







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 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.


















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 [paywalled]


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 and for each installed rpm package (before any new packages were installed):

20180329_kalkin_rpm_package_info_and_dumps.tar.gz


The results of running 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:

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








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 .
- 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.



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:



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



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 command.

Example:


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

The -a option means "append".

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 ().

Note: 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 flag for the command so that it will interpret backslash-escaped newline characters.




Example of capturing output sent to standard error:





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 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 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 will properly check for dependencies, even if the requiring package ends up being installed before the providing package.

I used , or rather .

Final command and its output:




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:



This is equivalent to running:




The default database location for RPM is .


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 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 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:




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 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.

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


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 option.

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








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:



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:




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 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:



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 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 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.















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).




Move over to Kalkin:




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 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 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.





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 documentation tool available on Kalkin?



Nope.


Move over to Kalkin:

Insert memory stick.




Output hangs. Press enter. New prompt appears.





Ok, workspace is set up.


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





Why is rpm listed in 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 to record the output, and I'll add it to this log after recovering it.

Note: I have found that the output of 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 output to the work computer, and then correct it while the original output can still be viewed.






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 .




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 can record command output
- how to mount/unmount a memory stick
- recovering and formatting the log produced by
I won't record the use of these items during the rest of this log.







Ok.


Switch back to Kalkin.






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 and produced no information about the package. I'm glad that 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 .

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

I'll try using .





I suspect that the 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).

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.





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





On Aineko:





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

I note , 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





Comments:
- All five items expect to find a key stored at .
- 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.
- is used on the last two items, which is probably why they didn't appear when I ran e.g. .
- I can probably use to disable the first three items.
- 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.





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.



vi is available.



Let's look at basic 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 to open the file 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.




Good.



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

In the .repo file, the key location was:


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 .
- 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 ) 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:


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




It's available.


Switch to Kalkin.






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 flag for the command to interpret backslash-escaped newline characters.

The output of the following four commands is omitted.




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





During the rest of this project, I won't record my use of to store output and transfer it to this log.


The 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.






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:
"

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.

makes sense, given that this command on the man page:
will display all currently imported public keys i.e. all packages whose names begin with "gpg-pubkey".


Switch back to Kalkin.






Hm.

How many packages are there?



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

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

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.




Hm. Nothing.




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:







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 command.


From running this command earlier:



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 :


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.





gpg is available.


Switch to Kalkin.





Some reading suggested a candidate for getting the key ID:


At this point, I made a mistake. I ran without using to record the output (nor did I record it manually). I then ran , which wiped this output off Kalkin's screen.

Running again did not produce the same output (it's much shorter this time).




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 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 for the first time caused gpg to create a keyring, which resulted in additional output.





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.









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 was meant to be .

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:


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






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.






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











Note: This line:

was not recorded in the output of .


I remember now that 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.

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 , 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 (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
consists of lines such as:

- 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 , 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 should probably have been .

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.





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

here for ease of reference:





I see that is called postinstall and preuninstall. It installs and uninstalls the file .

appears in the output of

(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




The install-info tool is provided by the package info-4.13a-8.el6.x86_64.




I'll copy the output of

here for ease of reference:





Hm.

"gdb" appears in the output of 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
.




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

or in the output of


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.




Nope. 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.





Nope. gdb is not installed on Kalkin.


How many files are registered in the rpm database?



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 utility installed on Kalkin.






Hm. Well, man page files turned up in the output of


/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-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 to view the file on the mounted filesystem before unmounting it, the entire file is present.
- Avoiding the utility by using instead of 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.




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?





Yes.

I'll unzip it before I transfer it to Aineko.





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

here for ease of reference:



Perhaps gcc-4.4.7-18.el6.x86_64.rpm also includes gcc 4.4.4-15 (invoked via command-line option?).

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

here for ease of reference:




/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: requires a filepath. If used with a filename or relative filepath, it will prepend the current working directory to the file name/path.





/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.




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 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







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

is similar to rtld(GNU_HASH), with (GNU_HASH) as an addition to the name.

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 .

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 on Kalkin and see what it produces.

Note: Earlier, I found that Kalkin's version of rpm is 4.8.0.







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?





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.





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.





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.




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





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.




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.







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?





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

.

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 ) or a temporary gpg keyring in order to use gpg to check a package's digital signature.







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:



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.






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 .

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

here:








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 (, for example ) 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 , e.g. .
- Statically compiled library filenames have the format , e.g. .
- Header filenames have the format , e.g. .
- Version-less symlink filename format: .
-- Example: -> .










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 and 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.






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.




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.






Note: The above output is error output. To redirect this output successfully to , add .
Example:




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.




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.







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.




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.







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 , or rather .


I'll do a test install, then an actual install.





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.






On Aineko, save this list as list_new.txt.

Save the old list of available packages as list_old.txt.





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.











On Kalkin, using vi, create a new file, write the following code into it, and save it as .









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 , 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:




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.










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.