HISTORY.devel-fork

HISTORY OF THE DEVELOPMENT BRANCH FORK
======================================

Eray Özkural

1. Introduction

PISI was the Pardus Linux package manager, I wrote most of it while
working at TUBITAK/UEKAE during 2005-2006 as a researcher, and it took
me about half a year to write it, and another half year to revise it
(80-90% of commit numbers/size), save for build commands, and the
actionsapi library, and I personally made the original 1.0 release at
Pardus, fixing 300+ bugs and wishlist issues. Then, my hopelessly naive
co-workers brought in another maintainer to the team who did
not contribute anything new to the code except for a bugfix somewhere,
but only stripped down some of the new features, mistaking this
destructive act for "maintenance" (he was only a contributor, not an
author). The latter releases do not have much that is new added to the
code, they've only stripped down some features and commands like the
search API. They've also tried to remove my name from the AUTHORS list
and from individual sources, in an attempt to hide my contributions,
pretending that PISI was written collaboratively. It was not. I wrote
most of it, I was the only seasoned programmer who worked on PISI,
amazingly, it turns out that it does take some skill to design an
efficient system tool; I was also one of the few ones who weren't
overtly lazy and did not spend the entire day writing blogs about
irrelevant stuff and drinking tea and tobacco like a state
officer. The Turkish Linux Users Group award for PISI was also given
to me personally, not the team. I left the award trophy as a gesture
of kindness to promote team unity. Since I am not pleased with the
later Pardus release branch that I find to be desecrating my poetic
code, I am reviving the original development branch. I've uploaded the
last development branch I found on my local SVN copies, out of
1.1_beta12. The next release will be 1.2, and then the next major
revision will be called 3.0. I declare the 1.0 and 1.1 releases
and 2.x branch from TUBITAK, which is not truly a major revision to
PISI code, to be obsolete. May its bits rot in peace.

To be absolutely clear, the last release I committed was 1.1beta9,
and it may be found here:
https://github.com/pars-linux/pisi/tree/3f94e538ec14b945271b5123efcabe934b1bbdb6

You will find that there have not been many interesting additions since then,
save for some code reorganization that moved files and functions around.
I noticed that most of the latter changes amount to crippleware, and
I am only selectively backporting some stuff like mirror support for the sake
of backwards (back to the future?) compatibility.

2. Novelties in PISI

There are two very interesting generic python novelties I developed
for PISI. The use of metaclasses was essential to both. The first one
is something I call autoxml, and it uses python metaclasses to work
with XML based configuration using Berkeley DB, but the DB is
completely abstracted. It's basically a neat nosql python XML/DB
framework. The other interesting thing is the command framework using
metaclasses, which also worked beautifully. The algorithms are also
pretty compact. I designed and implemented some graph algorithms to
deal with dependency resolution, and so forth. These algorithms make a
pretty useful library, you can write a lot of effective package tools
around the PISI framework, as we proved in the server scripts of
Pardus GNU/Linux distribution.

PISI also has some features not found in any other package manager
that I know of, such as the ability to work with hierarchical
components and metadata information in a clean, non-kludgey way, and
the smooth merging of binary and source package approaches of debian
and gentoo. PISI is sort of like gentoo package tools ported to debian
and debian package tools ported to gentoo, and rewritten in python in
a better way. Admittedly, there are some missing features, the
handling of virtual packages leaves something to be desired, I really
should rewrite that part, it's the same old problem with debian
package resolution, but unlike debian, both dpkg and apt-get layers
are implemented in a single library, no silly perl scripts and the
like. Even making everything pure python scripts was a huge
contribution. Caglar's actionsapi was also quite nice, Caglar was very
hard working, he developed most of the packages himself. Baris
contributed some nice bugfixes and developed most of the build path,
which does something a lot like gentoo. Getting both the binary and
source packages work seamlessly was an important feature of PISI, and
again, not really found in any other package manager the way it is in
Pardus. Although more than 10 years old, I suspect, PISI remains the
most compact, featureful and efficient package manager of all.

3. PISI Design

The design of PISI was based on a document about an XML format
designed by Pardus developers before I joined the team. I saw that it
is basically the same thing as dpkg, so I made a minor revision to the
document, and added a whole lot of features that I had designed as an
addition to dpkg / apt-get, such as the ability to deal with source
packages in the right way, the unique versioning / revisioning schema
of PISI, package / component / is-a models, dependency system, and
proposed to write the project in python. The most critical design and
features belong to me, such as the XML based data structures, autoxml,
the databases, the graph and dependency algorithms, the commands, the
CLI, search API, the first GUI, documents, translations, and so
forth. I am still amazed at how short the code is for what it does,
thank you Guido for python! All those cool python features like list
comprehensions and metaclasses did something for me, after all.

4. Development branch goals

The development branch's goal is to make the Pardus dependencies
optional. My vision for PISI was beyond Pardus, I had designed it as a
replacement for dpkg. It can replace dpkg/apt-get in a debian based system,
or gentoo package manager in a gentoo based system, with some due
effort, of course. Because of their sheer incompetence, TUBITAK later
dropped the PISI based Pardus distribution unwittingly and replaced it
with a Debian based distribution, when what they really needed was a
competent development team that could improve the, IMHO quite
satisfactory, system tools. However, the heart of Pardus is still the
PISI package manager, and naturally the other system tools such as
Gurer's COMAR and MUDUR, Baris's YALI. Those four tools + PISI packages make
a Pardus distro. I will not bother trying to rewrite COMAR and YALI,
but I have other ideas that will make PISI a portable package manager,
which is most of the reason I decided to write it in python. There are,
however, distros that are Pardus derivatives, and I will make a good
effort to support them with a reference implementation of PISI that
they can use or derive from.

5. Remarks

Let me know what you want to call the package manger in English, I'm
considering various alternatives. Kitty, and pussy are among the names
I'm considering. PISI means Packages Intended Successfully as
Intended, but I made that up as a de-acronym for PISI which is an
affectionate word for a cat in Turkish (like pussy), which was a name
decided before I even designed the code, çomar likewise is a slang for
dog in Turkish. I love my PISI, of course. <3

Happy hacking! :3

Dr. Kitty, aka Eray Ozkural, exa.

2017, Istanbul, Goztepe