ERKAN IŞIK / Atölye / 13-10-2021 / 18


Pisi stands for (Packages Installed Successfully as Intended). It is a small but full of features package management system.

It performs functions such as building, installing, uninstalling, upgrading packages by tracking dependencies. It has a user-friendly graphical interface and a comprehensive command line interface. It provides a familiar and simple development environment for developers.

PiSi packages

PiSi packages are archives in PKZIP format. It includes XML file named metadata.xml that contains the necessary information about the package apart from the files contained in the package and the scripts run after installation / before uninstallation along with ÇOMAR’s configuration scripts.

Package sources are a defination file named pspec.xml and a Python script named for structuring & buildin the source code containing the necessary commands to be built and placed in the desired directory. In addition, it contains patches other scripts and additional files.

​Characteristic features

PiSi is written in Python, thus ensuring portability and small program size without losing performance. Resource packages consist of simple XML files and Python scripts

Packages are defined with a short and understandable build recipe as in source-based package systems, developed for this an API collects the common required commands.

It combines high-level and low-level package management functions in one software. It doesn't need extra software to track dependencies or manage repositories. It uses Berkeley DB to keep track of package information such as which file is in which package and dependencies.

Dependencies are calculated with fast algorithms. Packages are organized by components and categories. Binary packages are in PKZIP archives. URL, HTTP and FTP support is transparently provided in many processes. For example, a remote resource can be built by simply providing a pspec.xml URL. It shows the source archive by URL, does not contain the original source code, so this makes it easy to develop with “version systems” such as subversion. It is easy to develop applications on it as it is designed in a library way.

Gettext internationalization, which is widely used in free software, is used for program messages, and xml:lang internationalization is used for xml files.

​Repositories and dependencies

Repositories are defined by the URL of an XML file (pisi-index.xml) containing an index of packages under a directory. Package dependencies are tracked by using well-known simple graph algorithms. First, the required subset of package is fetched from the database with the least number of accesses needed, then a simple but safe plan is calculated with “topological sort”. The plans created for package installation, removal, and upgrades keep the system consistent in the event of a failure. Upgrade plans take into account both straight and reverse dependencies. A safety catch prevents important packages from being removed by default.


An important problem in software distribution is keeping track of development history. PiSi has characteristic solution which is to separate package source and binary package build versions. The package version number shows how many times a package source has been modified and the package build number indicates the rank of a binary package. Thus, the version number divided into different sizes solves some problems encountered in practice.

​Component / Categories

An organization is required because the number of resource packages is so large (around 800 at the time of writing). Web Ontology languages are too complex for software packages. According to our research, specifying only two relationships is enough for basic requirements:

A package x is a part of component y

A package x belongs to category y

Here the component shows a subsystem of Pisi Linux. For example, system.base is the base system running in the console, while desktop.kde is the KDE desktop. A package can be part of a single component, so components are a group of packages. system.base and system.devel are special components. All applications need the base UNIX environment provided by system.base. The necessary resources for the package build command are in system.devel.

The category indicates the package type. For example, app:gui shows graphical apps, app:cli shows command line apps, and library shows libraries. A package can have multiple categories.

​Search functions

Searching keywords (search command) works on summaries and definitions. It is multilingual and uses an “inverted index” for fast processing. Search-file command finds package by filename as well.

​Database structure

The Berkeley database has been chosen because it is customizable and flexible (e.g. easy to store lists etc). All intermediate data is stored as XML. XML structures are automatically transferred into Python objects. In case of emergency the entire database can be recreated from stored XML files (rebuild-db command).

​PiSi command line

The SVN style command line processor contains 29 commands. Distinctions according to command types are shown below.

Info & search commands: search, search-file, info, list-available, list-components, list-installed, list-pending, list-repo, list-upgrades, graph
Repository commands: index, add-repo, remove-repo, update-repo
Building package: build, build-until,build-build, build-install, build-package, build-setup, build-unpack

Binary package process: install, remove, upgrade, check, configure-pending
Auxiliary commands: rebuild-db, clean, delete-cache
You can refer to the Pisi CLI usage document for detailed usage examples.

​Graphical interface

Graphical interface is as simplified as possible to use. It consists of a single window for all operations and a window for repository settings. There are three modes for package operations (upgrade, install, uninstall). The search function is provided with a familiar search bar at the top of the packages. Packages are divided into components. It shows applications by default, all apps can be selected with a filter option also. The whole system can be updated with one click.

​Errors encountered while making Pisi Package and the solutions

Error.1: unpack: There is a problem with the integrity of the source archive.

Solution; You receive this error because the sha1sum value is incorrect. Press the F4 key in the directory where the file is located to decode the sha1sum value, then type sha1sum filename.tar.gz and press enter.

Error.2: PISI.source. description:

It is an error caused by the absence of the description tag in pspec.xml. At least one 'Description' tag must be in native text.

Solution; Add description tag in pspec.xml.

Sample image

An Exiv2 wrapper library

libkexiv2 is a wrapper around Exiv2 library to manipulate pictures metadata as EXIF/IPTC and XMP.


Error.3: XML syntax is invalid.

This error is caused by incorrect the tags in pspec.xml.




Both are the same line but “/” is missing in the first line

Error.4: There are abandoned files under the install directory.

Under the installation directory (/var/pisi/libmicrohttpd-0.9.2-6/install) there are abandoned files:


1 error, 0 warning

The program has been terminated.



The problem will be solved if you add the bolded line. Other path types you can add to the “Files” field


Error.5: Source package contains multiple 'Path' tags in /usr/include path

Solution; The solution is to not add multiple /usr/include paths in pspec.xml. Problem will be solved when you delete one of them.

Error.6: checking for GLIB – version >= 2.30.2… no

The reason for this error is that the glib version on your system is lower than 2.30.2.

All you have to do is making package in required version or higher.


Another error checking for GTK+ – version >= 2.24.10… no solution is the same.

Error.7: System failure. The application is terminated : not a bzip2 file

The reason for this error is that the type="tarbz2" field in the archive tag of the source file and the source file extension are different from each other. The solution is to replace the source file extension with whatever it is.

Correct one;

Incorrect one;

Error.8: An unknown type (tarbxz) is given for the archive: You will have this error because automake-1.11.4.tar.xz file extension is written type=”tarbxz”. Correct one should be type=”tarxz”

Error.9: error: ‘/usr/bin/qmake’ is not a file (this error has been seen in enterprise 2.)

Usage: python [opts] [macro=value] [macro+=value] error: ‘/usr/bin/qmake’ is not a file

DEBUG: “python -q /usr/bin/qmake” dönüş değeri 2

Traceback (most recent call last):

File “/media/Depo-2/pisiyap/python-qt/”, line 19, in setup“ -q /usr/bin/qmake”)

File “/usr/lib/pardus/pisi/actionsapi/”, line 80, in run

if system(‘python %s’ % (parameters)):

File “/usr/lib/pardus/pisi/actionsapi/”, line 255, in system

error(_(“Command ”%s” failed, return value was %d.”) % (command, retValue))

File “/usr/lib/pardus/pisi/actionsapi/”, line 27, in error

raise Error(msg)

pisi.actionsapi.Error: “python -q /usr/bin/qmake” komutu başarısız oldu, dönüş değeri: 2 .

The reason for this error is that the requested file is not available at the address on the second line in See below:

def setup():

pisitools.dosed(“”, ” check_license()”, “# check_license()”)“ -q /usr/bin/qmake”)

Make required changes to solve the problem.

def setup():

pisitools.dosed(“”, ” check_license()”, “# check_license()”)“ -q /usr/bin/qmake-qt4“)

Error 10: Patch file missing:

pisi bi –ignore-sandbox pspec.xml -d

Resource pack being built: gdb

The program has been terminated.

Patch file is missing: suse/gdb-bz541866-rwatch-before-run.patch

The error is the missing file in the build files you downloaded.

Solution: The solution is to add mentioned file in files/suse/.