Package Management – Pardus Package Manager: PISI

Package Management – Pardus Package Manager: PISI
Page content

Introduction

There are many derivative distributions in the Linux world. If we look at the top ten distributions on Distrowatch, we can see Ubuntu and Mint, which are derivatives of Debian; Fedora and Mandriva which are derivatives of Red Hat; and PCLinuxOS which is a derivative of Mandriva. All these distributions use the main distribution’s package management system. Debian based distributions use the dpkg package manager and Red Hat based distributions use the rpm package manager.

The Pardus distribution uses a totally different package management system, called Packages Installed Successfully as intended or PISI. In Turkish, pisi means “kitty”, which is an intentional analogy to Pardus, the Anatolian Leopard. PISI developers criticized the existing package managers (dpkg, rpm, ebuilds, etc.) and their wrappers (apt, urpmi, yum, etc.) and have picked the best features from them and built the package management system from the ground up using Python.

What is Different with PISI?

The main differences between PISI and other package managers can be summarized as follows:

  • the main roles of the package management--installing and building software packages, dependency resolution, repository management, package signature verification, and package downloading–is the core of PISI
  • the package configuration is a separate task and delegated to the Configuration Manager or COMAR
  • with the 2009 release of Pardus, PISI introduced delta packages which are similar to delta rpms. Delta packages hold information about “what’s new” with the package and installs only the differences. This saves the user from downloading the entire application

In mainstream package managers, such as apt, the “housekeeping” job, keeping track of the installed packages, is done by the dpkg application and the wrapper, apt, handles dependency resolution, package selection and installation issues. This is where PISI is different–package configuration is not handled by the package manager. Second, traditional build scripts are shell scripts, which present high costs for maintenance and debugging (shell scripting needs additional helpers and tools, which bring their own syntax and usage, and in turn which developers/packagers need to learn to build packages). Third, PISI configures packages before installation, similiar to Gentoo’s emerge, presenting a more efficient installation. If this is how the user chooses to proceed, the source repository has to be added to PISI’s configuration. Fourth, it brings the “scenario” concept, enabling developers and administrators to test their builds and installations before committing a whole implementation.

PISI Front End

PISI has only one front end, the PISI Package Manager, which is looks very similar to Adept. The left pane presents the package category and the right pane displays the applications for the selected category. A small description is added under each package name.

Conclusion

PISI brings new life to existing package management systems with its simplicity and ease of use for the end user, while presenting a Python-based development environment. Developers who have a working knowledge of Python and XML will find it relatively easy to grasp the PISI basics and build packages. By picking the best features from each package manager, PISI is ready to be implemented in the mainstream distributions.

If you are interested, check out the latest Pardus release review.

This post is part of the series: Linux Package Management

In our series about the package management process in Linux, we will start from scratch, talk about the software packages, the dependencies, their resolutions and then analyze the package management systems of the mainstream Linux distributions.

  1. Understanding Package Management
  2. Debian’s APT - Top Package Management
  3. Red Hat’s RPM
  4. Slackware’s Pkgtool and Slackpkg
  5. Pardus’s PISI