Home Classroom Linux Basics Linux Basics Part 6

Linux Basics Part 6

1037

Package Management System Options

In the new year let us try to understand something slightly more advanced than our previous topics. We finished the last article telling you that we shall be discussing package management on Linux systems and pointing you to an article on Wikipedia. Those who saw the Wikipedia page might already have a basic idea of what we are about to start discussing today.

There are quite a few ways to install software in a Linux system. We will be getting introduced to a few common methods during this article. It could help you in the long run to decide between Linux distributions based on the package management criteria. However please remember that some of the methods and tools are quite uncommon while the rest is more or less popular. So there is no need to intimidate yourself with the variety of methods available.

 

Software and package management

First of all, you might be wondering why are we talking about this at all. Let us see why.

If you have used any computer operating system before, then you may be familiar with the concept of installing and uninstalling software on that system. What we mean by the term package management is essentially the same. So software package management is managing the install, update and uninstall of software.

A software package is a bundled collections of files, directories which form a software. A package can come in many formats. Those who come from the Windows world might already know of .msi type packages. In Linux also there are software packages. What we are going to discuss today is some of those package formats and how to work with those.

 

New Concept: Software Package

So you now know what package management is. What is a package anyway?

A package is a collection of files and metadata bundled into form a distribution of a software. From this point onward it is important to remember that a single software project might be distributed in several packages. Let us take the example of gedit, which is the default GUI based text editor on a lot of Linux systems. gedit usually comes split in to a few packages. In the Fedora Linux distribution, they are as follows:
gedit : Text editor for the GNOME desktop
gedit-devel : Support for developing plugins for the gedit text editor
gedit-plugins : Plugins for gedit

As you can see there are more than package containing the parts of gedit. The part everyone care is the package named “gedit”. It contains the executable gedit which will invoke the gedit editor. The package gedit-plugins contain the additional plugins which will provide extended features for the editor.

 

New Concept: Package Dependencies

As you saw in the previous section, some software projects are split into several different packages. In the previous example we saw gedit and gedit-plugins. So what would happen if we try to install just the gedit-plugins package, without the gedit package?

As we know gedit-plugins provide extended features for the gedit editor. However without gedit the gedit-plugins package has no purpose and cannot function. In such as situation, the system (with the help of the package management system) knows that the user should not be allowed to install gedit-plugins without gedit itself.

 

So are you thinking what immediate benefits are there of using a package management system? As we already know it makes installing software easy by handling dependencies. Then when you want to update your installed packages, a package management system will automate most of the process making it much easier than to update manually. In the case where you want to remove a software, you would have to go and delete all the files/directories and then the metadata manually unless you are using a package management software.

These are the most obvious and straight forward reasons to use a package management system. Sure, it adds a bit of a complexity. But as the benefits well out weight the added overhead. This is why all the major operating system support at least one proper package management mechanism by default.

 

New Concept: Package Types

In Linux there are at least two major package management systems and many more in the wild. This has given the rise to many different package formats. If you had tried installing some software on your Linux distribution of choice you might have already noticed a few different types. A package format is essentially a agreed upon standard way of putting a collection of files and metadata together.

 

Yum and APT (or RPM and Deb)

Yum and APT are arguably the most popular package management tools around for Linux. These respectively utilize package types RPM and Deb.

RPM initial stood for Red Hat Package Manager, but nowadays it just means RPM Package Manager. RPM is a package format which was initially developed by Red Hat and then adopted by SuSE, Mandriva (Mandrake) and many more. The popular Fedora distribution is also using RPM package format. Deb format of packages were initially developed by the Debian project, but are utilized in many other projects such as Ubuntu.

RPM and Deb packages can be manipulated within the system with the use of tools like rpm and dpkg respectively. For example here is how you install a software using those commands.

Eg: Install software package using 1st level tools
On Fedora
# rpm -ivh somepackage-1.0.0.rpm
or
# dpkg -i somepackage-1.0.0.deb

Eg: To uninstall a package:
# rpm -e somepackage
or
# dpkg -r somepackage

 

While these basic tools provide a useful method of working with packages, the high level tools such as yum and apt-get makes things very easy to handle. Let us take the following examples.

Eg: Search the package repositories for a package with a name matching a pattern
# yum search mysearch
or
# apt-cache search mysearch

Eg: Install a package from the repositories
# yum install mypackage
or
# apt-get install mypackage

Eg: Uninstall package
# yum remove otherpackage
or
# apt-get remove otherpackage

Eg: Update a package
# yum update updatepackage
or
# apt-gate update updatepackage

 

Portage, Pacman and others

While Yum/APT based package managements systems are the post popular they are by mo means the only options out their. Probably the most popular out of these alternative tools is the Gentoo Portage system which was inspired by the FreeBSD Ports systems.

Then there is other package management systems like Pacman tool available in Arch Linux and a several other different and more archaic systems.

 

PackageKit, SmartPM and the Hybrids

In the recent year there have been attempts to create more abstract package management tools which acts effectively as a frontend to existing package management tools. Perhaps the first popular attempt of this nature comes from the Smart Package Manager. However in the past few months a newer systems has taken a clear lead in this front; PackageKit

Originally developed by the innovation driving Fedora project, PackageKit aims to provide a common frontend to existing package management tools. It complies to the standards of the FreeDesktop.org and also integrates with PolicyKit, a framework to manage privileges in Linux systems. By today a number or major Linux distributions uses PackageKit/PolicyKit such as Fedora, Ubuntu/Kubuntu, OpenSuse, Foresight, etc.

 

It is always good practice to try to install the software using these package management tools. But in order to use these you will need to find a pre-packaged version of the software you are interested. Unluckily not every software is packaged. Software authors sometimes opt to not package their software at all owing to several reasons. One such common reason is the variety of package formats they need to convert to. To this end some of the software projects only provide an executable installer package or just a source code bundle.

 

Executable Installers

Various reasons prevent prevent authors from using conventional package manager compatible bundles. So some of them choose alternative executable installer options. Some of these installers are GUI based and some of these are command line based or both. This method of software delivery is usually discouraged as they bypass the package manager.

One common source of such delivery is commercial software vendors. While some companies like Adobe (Reader, Flash Player) and Google (Chrome, Picasa) provide traditional packages such as rpms and debs, some companies prefer executable installer approach. For example various game vendors who ship Linux versions of their software choose to a GUI based installer. The advantage of this approach is that it might be familiar to those who are from the Windows world. The obvious downside is that this will bypass the package manager thus making it unaware if the availability of that software. Which also means that if some other package requires it as a dependency, the package manager wouldn’t know that it’s already installed in the system.

One popular GUI based installer for Linux environment is BitRock Installer which can build installers to multiple target environments including Linux, Mac and Windows. In addition they give you the option to generate traditions RPM/Deb packages from your software.

Some of these alternative installer systems provide their own tracking system. For example Autopackage and Zero Install programs keep track of the software installed installed through them.

 

Compiled Software Archives

Some software are provided in an ready to run bundle format. You just need to extract them somewhere convenient for you and then run the software. For example some games such as Nexuiz and Urban Terror are provided in this manner.

 

Source Distributions and Tarballs

One of the most common package types you would encounter with FOSS projects is a source distribution. They are usually bundled into what it know as a tarball (i.e.: tar.gz or .tar.bz2). Extract such as archive and you will get the source code of the particular software. Then you have to build yourself.

To extract a source archive you can either use a regular GUI based tool (Eg: right click and select, Extract Here) or a command line. Here is how to use the command line with the different type of tar archives.

Eg:
tar.gz – $ tar xzvf package.tar.gz
tar.bz2 – $ tar xjvf package.tar.bz2
tar.lzma or tar.7z – $ tar –lzma xvf package.tar.lzma

After this point you can either to compile & build the software or build & generate a package. There is no specific instruction from here onwards. You have to refer the install instructions for further instructions. These can be found usually inside the files INSTALL and/or README inside the source directory.

In common cases running the following 3 commands in sequence should suffice, but remember that there is a few popular build systems and some software need specific requirements to be built.

Eg:
$ ./configure
$ make
$ sudo make install

Due to the possibility of a number of various scenarios, it is not feasible to describe every situation when building a software from source. Therefore it is highly recommended that you refer to the instructions from the particular software distribution.

One obvious downside of this approach is again, this process bypasses the package manager.

 

As you can see downloading some piece of software from Internet and installing it can be no-so straight forward in Linux. But the variety usually means there is a lot of flexibility. However as a beginner to the Linux is is highly recommended you use the provided software channels (Eg: package repositories) with the preferred tools. There are nice GUI tools to query, select and install/uninstall software from those channels without much trouble. Just look under System –> Administration or Applications –> Systems Tools menus to find such applications if you are using a GUI. If you are using only the command line, or prefer to use it the most convenient way is to use a tool like yum or apt-get.

However with the advent of PackageKit-like systems the software installation process seems to be going in a unifying direction, which can be a good thing. As of now, remember it is always best to go with a package management system. Even in its current state, only some reasonable adapting is required from you to be comfortable with managing software on Linux. Once you get use it, it will seem much organized with probably preferred workflows.

In the next issue, we will be discussing how to use Yum and APT based package management tools (i.e. how to use package management tools in Fedora/Red Hat and Debian/U

Comments

comments

Gaveen is a Linux System Administrator with several years of industry experience and is a strong FOSS promoter. He is pending graduation from University of Wolverhampton and also holds a certification from Red Hat. He also conducts Linux trainings with Red Hat training partners. Being highly enthusiastic about computing, he supports a keen interest in Ruby programming too. When not distracted by his wide range of interests including reading, music, cricket, etc.,he regularly blogs at Gaveen's Blog

NO COMMENTS

Leave a Reply