Operating systems 
Package Management and 
Configuration 
 

M.Karanraj (17pw18) 

18th March 2019 

1 
 

Introduction 

A package management system or a package 

manager is a collection of software tools that automates 
the process of installing, upgrading, configuring and 
removing computer programs for a computer’s operating 
system in a consistent manner. 

Package managers typically maintain a database 

of software dependencies and version information to 
prevent software mismatches and missing prerequisites. 

Package managers are designed to eliminate the 

need for manual installs and updates. This can be 
particularly useful for large enterprises whose operating 
systems are based on Linux or Unix-like systems, typically 
consisting of thousands of distinct software packages. 

There are two types of package managers, 

● System level package manager 

● Application level package manager 

2 
 

Why do we need Package Managers?  

Application developers today are used to relying 

on and pulling in a number of open source libraries to help 
them focus on the functionality that’s important to their 
business. Rather than requiring you to find and download 
each of those libraries individually, most programming 
language ecosystems have a standard package manager 
that helps you to install and manage those libraries. 

In short, package managers prevent coupling the 

code base with library code bases. Updating softwares are 
made simple and automated by the package managers. 

Examples:  

● Ruby  -  RubyGems 
● Python  - PyPi 
● Java - Maven 
● Javascript - NPM, Jam 
● Objective C - CocoaPods 

   

3 
 

LINUX and the need for package manager  

As the linux kernel began to see broader usage, 

people wanted and needed to have more than just an 
operating system kernel. At first, it was the basics such as a 
shell and utilities such as cut, sed and awk and an editor 
such as vi or emacs. 

In 1993, dpkg and rpm came into effect. These are 

the earliest examples of package managers. Amazingly 
Debian still uses dpkg and Red Hat still uses rpm. 

Functions of a package manager  

A software package is an archive file containing a 

computer program and necessary metadata. The computer 
program can be in the source code that has to be compiled 
and built first, whereas the metadata include package 
description, package version and dependencies. Package 
Managers can be charged with the task of finding, 
installing, maintaining or uninstalling the software packages 
upon the user’s command. 

4 
 

Typical functions of a package management system 

include 

● Working with the file archivers to extract package 

archives. 
● Ensuring the integrity and authenticity of the package 
by verifying their checksums and digital certificates. 
● Grouping packages by function to reduce confusion. 
● Looking up, downloading, installing or updating the 
existing software from a software repository or app 
store. 
● Managing dependencies to ensure a package is 
installed with all packages it requires thus avoiding the 
dependency hell. 

  

5 
 

Package Management: How to do it?  

There are two basic approaches 

● Some package management systems concentrate on 

the specific steps required to manipulate a package. 
● Other package management systems take a different 
approach, keeping track of the files on the system and 
manipulating packages by concentrating on the files 
involved. 

Each approach has its own good and bad points. 

In the first method, it’s easy to install new packages and 
somewhat difficult to remove old ones and impossible to 
obtain any meaningful information about installed 
packages. 

The second approach makes it easy to obtain 

information about installed packages, and fairly easy to 
install and remove packages. The main problem using this 
method is that there may not be a well-defined way to 
execute any commands required during the installation or 
removal process. 

6 
 

In practice, no package management system uses one 

approach or the other — all are a mixture of the two. The 
exact mix and design goals will dictate how well a 
particular package management system meets the needs 
of the people using it. At the time Red Hat started work on 
their Linux distribution, there were a number of package 
management systems in use, each with a different 
approach to making package management easier.  

ANCESTORS OF RPM 

RPP  

RPP was used in the first Red Hat Linux 

Distributions. Many of RPP’s features are similar to RPM. 
Some of these innovative features are 

● Simple, one command installation and uninstallation of 

packages. 
● Scripts that can run before and after installation and 
uninstallation of packages. 

7 
 
● Package verification: The files of individual packages 
can be checked to see that they haven't been 
modified since they were installed. 
● Powerful querying: The database of packages can be 
queried for information about installed packages, 
including file lists, descriptions and more. 

Though it had several important features, it had some 

weaknesses too, the major one being the lack of usage of 
“pristine sources”. They are rectified by the PMS.  

PMS  

Like RPP, PMS was used to package a Linux 

distribution. This distribution was known as the BOGUS 
distribution, and all the software in it was built from original 
unmodified sources. Any changes that were required were 
patched in during the processing of building the software. 
This is the concept of "pristine sources" and is PMS's most 
important contribution to RPM. The importance of pristine 
sources can not be overstated. It allows the packager to 
quickly release new version of software, and to 
immediately see what changes were made to the software. 

8 
 

The chief disadvantages of PMS were weak querying 

ability, no package verification, no multiple architecture 
support, and poor database design.  

PM  

The PM’s design combined all the important 

features of RPP and PMS including one command 
installation and uninstallation, scripts run before and after 
installation and uninstallation, package verification, 
advanced querying, and pristine sources. However it 
retained RPP's and PM's chief disadvantages: weak 
database design and no support for multiple architectures. 
PM was very close to a viable package management 
system, but it wasn't quite ready for prime time. It was 
never used in a commercially available product.  

RPM Version-1  

RPM was written in Perl programming language 

for fast development and was focussed on addressing the 
flaws of its ancestors. 

9 
 

SUCCESSES  

● Automatic handling of configuration files. The contents 

of config files are often changed from what they were 
in the original package, making it hard for a package 
manager to know how a particular config file should be 
handled during installs, upgrades, and erasures. PM 
made an attempt at config file handling, but in RPM it 
was improved further. In many respects, this feature is 
the key to RPM's power and flexibility. 
● Ease of rebuilding large numbers of packages. By 
making it easy for people who were trying to create a 
Linux distribution consisting of several hundred 
packages, RPM was a step in the right direction. 
● It was easy to use. Many of the concepts used in RPP 
had withstood the test of time and were used in RPM. 
For instance, the ability to verify the installation of a 
package was one of the features that set RPP apart. It 
was adapted and expanded in RPM version 1. 

Its successes were tremendous. However it had some 

flaws too. 

10 
 

FLAWS  

● It was slow. While the use of Perl made RPM’s 

development proceed more quickly, it also meant that 
RPM would not run as quickly as it would have, had it 
be written in C. 
● It was big. This is another artefact of using Perl. 
Normally, RPM's size requirements were not an issue, 
except for one area. When performing an initial system 
install, RPM was run from a small, floppy-based system 
environment. The need to have Perl available meant 
space on the boot floppies was always a problem. 
● The package file format wasn't extensible. This made it 
very difficult to add functionality, since any change to 
the file format would cause older versions of RPM to 
break. 
● Its database design was fragile. Unfortunately, under 
RPM version 1 it was not unusual for there to be 
problems with the database.  

The flaws of Version-1 has been corrected in the Version-2 

though perfection couldn’t be reached in any of the 
upcoming versions.  
11 
 

RPM Version-2  

Some of its key features are 

● This version was entirely written in C. This did 

wonderful things to RPM’s speed and size. Querying 
the database was quicker now, and there was no need 
to have Perl around just to do package management. 
● In addition, the database format was redesigned to 
improve both performance and reliability. Displaying 
package information can take as little as a tenth of the 
time spent in RPM version 1. 
● Realising RPM's potential in the non-Linux arena, they 
also created rpmlib, a library of RPM routines that 
allow the use of RPM functionality in other programs. 
● RPM's ability to function on more than one architecture 
was also enhanced. Finally, the package file format 
was made more extensible, clearing the way for future 
enhancements to RPM. 

Though it is not perfect, as a package manager that can 

run on several different types of systems, RPM has a lot to 
offer and it will only get better. 

12 
 

RPM Design Goals  

● Make it easy to get packages on and off the system. 

● Make it easy to verify a package was installed 
correctly. 
● Make it easy for the package builder. 
● Make it start with original source code. 
● Make it work on different computer architectures. 

Maintenance of configuration  

Particularly troublesome with software upgrades are 

upgrades of configuration files. Since package managers, 
at least on Unix systems, originated as extensions of file 
archiving utilities, they can usually only either overwrite or 
retain configuration files, rather than applying rules to them. 
Problems can be caused if the format of configuration files 
changes; for instance, if the old configuration file does not 
explicitly disable new options that should be disabled. 
Some package managers, such as Debian's dpkg, allow 
configuration during installation. In other situations, it is 
desirable to install packages with the default configuration 

13 
 
and then overwrite this configuration, for instance, in 
headless installations to a large number of computers. This 
kind of pre-configured installation is also supported by 
dpkg. 

High and low level package tools  

l​n order to perform the task of package management 

effectively, you need to be aware that you will have two 
types of available utilities:  

● low-level​ tools (which handle in the backend the actual 

installation, upgrade, and removal of package files) 
● high-level​ tools (which are in charge of ensuring that 
the tasks of dependency resolution and metadata 
searching -”data about the data”- are performed). 

These high and low level package tools have their 

respective applications which are listed below. 

14 
 

Common usage of low level tools  

● Installing a package from a compiled file (*.deb or 

*.rpm) 

● Upgrading a package from a compiled file 

● Listing installed packages 

● Finding out which package installed a file 

15 
 

Common usage of high level tools  

● Searching for a package 

● Installing a package from repository 

● Removing a package 

● Displaying information about a package 

16