Roadmap Pardus-Anka

[saygili]

Forget them. It was obvious, now clear.

Pardus, Anka, what ever you name it , will/should continue independently from Tübitak. There are already too many Debian based distributions. Why next one will be Pardus?

It is meaningless. What makes Linux is not the richness of package repositories. It is freedom, ease of use, ease of configuration, functionality. Pardus has all of these.

I think /hope good days are coming.

[atolboo]

..... Why next one will be Pardus?

It means a lot of resources can work on the uniqueness of Pardus.
Because they can work on the integration of all the settings in System Settings and other stuff.
Because maintaining a repo takes a lot of continuous effort.
Using Debian packages has its advantages and disadvantages.

Pardus, Anka, what ever you name it , will/should continue independently from Tübitak.

I hope this is possible with the available resources.
Maintaining it is quit a challenge.

[jasperodus]

I agree completely with atolboo.

Ideally Pardus (as we knew it) could continue but this does not seem at all viable, given the current/foreseeable resources.

Debian-based (and the unfortunate corresponding loss of Pisi) is a compromise. But what alternative: to forsake Pardus entirely? That is not logical or reasonable.

What exactly is Pardus? My definition of the true nature of Pardus: The distro itself is not the 'ultimate' and deeper meaning of what 'Pardus' really is - an expression of potential - and that potential (the spirit, if you like) existed prior to the distro, and it will continue to exist - as potential, regardless of the existence of the distro.

An analogy: a torch-light does not 'create' things (potential) as the beam moves around in the darkness - the beam is just a point of focus which 'gives expression' or 'makes real' the 'unrealized potential'.

Further analogy: If a person looks at a painting, for instance, and is moved - then there exists within that person, a certain resonance; a resonance prior even to becoming aware of the painting.

Pardus-the-distro was 'formed', or found expression from a formerly unrealized potential of ideals and principles and ethics...and more. The distro is essentially analogous to the result of a particular point of focus. Now, perhaps it is not possible to shine the 'light' in exactly the same place twice......but what I am struggling to relate, is my feeling that the people who 'believe' in Pardus: the passion and resonance of the community for the ideals that are the foundation of Pardus-the-distro.....that is the true seat of Pardus.

So, while it is a sad prospect to let go of the 'body' that we knew.......let us not 'forget' or loose the 'Spirit' of Pardus by the dispersal of the community drifting off to various other distros. I know there are perfectly good distros about - but not as 'personal?'

If a compromise is the only way - then so be it! Let the energy of the faithful who have remained thus far, as a community, be the focus for a Debian-based project to keep alive and build on the Spirit of Pardus.

Prior to the IRC meeting, I was not even aware of the fact that certain of the python-based elements of Pardus are theoretically transferable to to something debian-based.

Basically. If it completely unrealistic to continue Pardus 'as is', then I would accept the compromise of debian-based......corporate - or otherwise.


Thanks for listening.

[saygili]

@jasperodus
The problem is not only Debian, but also Tübitak. They want to close the Pardus project but not by themselves. They are trying people to leave by their own decision and close the shop.

For me, the spirit of Pardus is ,Pisi,Comar,Tasma,Kaptan,Yalı, but not the apt or aptitude.

This is something like you love a person but he/she is dead but soul lives somebody Else's body.

Where is the person I love? Body dead soul exists in somebody Else's body. 

For me like that but everybody has his/her own feelings.

There was a song "I will never dedicate my love to somebody else's lover"

Thank you all.

[dschzz]

The problem is not only Debian, but also Tübitak. They want to close the Pardus project but not by themselves. They are trying people to leave by their own decision and close the shop.

Agreed. All this, starting with trying to assign developers to different jobs / different places, announcing end of life, changes, proposed changes, Plans that are high in the clouds and so on, al that looks like "they" want to make it generally difficult for the project and while doing so, removing themselves from responsible positions - but still have a grip on control. Even the idea of using Debian as a base (which makes seriously sense if you don't care about Pisi but want a distribution that is easy to maintain and is backed with undoubted biggest package repository - yes, I really see the advantage, and it's a real one) leads to making it difficult for those who want to keep Pardus alive as it is.

For me, the spirit of Pardus is ,Pisi,Comar,Tasma,Kaptan,Yalı, but not the apt or aptitude.

Again I totally agree. On the other hand, loosing Pisi and being able to keep Comar, Tasma, Kaptan, Yalı is surely better than loosing everything. I'm too new to Pardus to be able to tell how much work it is to keep a repository up-to-date. With a Debian base, this work would not be a load on our shoulders. That's generally great and especially great considering our little resources. On the other hand, you cannot do anything yourself to fix a bug in a Debian package. All you can do is tell the maintainer of the package about the bug, and then wait. Getting rid of the workload means also loosing control of the packages. In the end, Pardus will be yet another Debian derivate with maybe 4 special tools.

Would that be enough?

For a company who just wants a free OS which meets some criteria, good usability and for some reason cannot or does not want to use Ubuntu, the answer would clearly be YES! These companies do not tend to be in a hurry when it comes to new stuff, be it hardware or software. When a bug is discovered, just don't spread the knowledge and wait until somebody fixes it.

But were these companies ever the targeted users of Pardus in the past?


And now I have a sort of technical question:
What were the reasons that Pisi was developed at all?

I mean, before I begin to develop something, I look around and try to learn as much as possible about the tools that are used by others for the particular use case. I don't just jump into it and develop something out of the blue and I believe that nobody would be so stupid. So there must have been reasons that were strong enough to initiate the development of Pisi, which is something completely new and incompatible with everything else and therefore obviously comes with the big disadvantage of needing to maintain one's own repositories - instead of just taking an existing tool like dpkg or synaptic and save a lot of resources. Can someone please give me one or more links where I can read about these reasons or just tell me about them?

(I understand that at this point, logic is completely out of the window, so the reasons of yesterday may still be valid and Pisi is sacrificed purely because a change is wanted.)


And another thought... Once the move to Debian is done, it may happen that other tools are more or less silently dropped because the Debian people do not want them, nobody takes care about them and there is no real need for them. Just saying.


And now something different, yet related... Very soon after I started with Pardus I thought: What if the original download servers are shut down, become unavailable or whatever - how much depends this community on them? On the longer run, we need our own server for the community version. Or at least set up a torrent and seed it forever...

[jasperodus]

For me, the spirit of Pardus is ,Pisi,Comar,Tasma,Kaptan,Yalı, but not the apt or aptitude.

I am not happy either. I wish that Pardus as we know it could continue (and continue to evolve and improve, as it did before), and I appreciate your equating those core components as representing the spirit. I tend to think that those components are part of an 'expression' of the spirit of 'The Pardus Way'. I know that is a bit loose – and, yes, in the 'real world', if you like, I too will regard the removal of any core feature as a loss (which, it would be), but I would consider the entire loss as a bit of a disaster.

For me, the ultimate tragedy would be the dispersal of the people who have the Pardus 'resonance', ending up using a perfectly serviceable alternative distro – but the 'painting' will likely not move us  quite as powerfully.

Why not channel it? If there is no other option, then I say, take whatever furniture we can, and let's fashion a house - using the 'Pardus Blueprint' - where we can feel more 'at home'.

[saygili]

Hello,

Here is the Pisi link. Why they have choosen.

http://www.brighthub.com/computing/linux/articles/52774.aspx

and

from
http://tr.pardus-wiki.org/Pisi_tasar%C4%B1m%C4%B1#Neden_P.C4.B0S.C4.B0.3F

Neden PİSİ?

Hali hazırda varolan ve geniş bir kullanım oranına sahip paket yöneticileri (RPM, DPKG ve Portage) yukarda saydığımız gereksinimlerin kimilerini bizim olması gerektiğini düşündüğümüz basitlikte yerine getirememekte, kimilerini de hiç vaad etmemektedirler. Bu paket yöneticilerinin geliştirilmesi ve istenen noktaya getirilmeye çalışılması yeni ve ayakları yere daha sağlam basan bir paket yöneticisini yeniden yazmaktan daha kolay değildir.

Daha önemlisi, varolan paket yöneticilerinin paket formatlarında görevleri ve bilgileri birbirinden düzgün bir biçimde ayrılmadıkları görülmektedir. Bu araçlar basit olarak hazırlanmış ve zaman içinde ortaya çıkan ihtiyaçları karşılamak için sürekli yeni özellikler eklenerek bugünkü hallerine gelmişlerdir. Bunun getirdiği karmaşıklığı temizlemek için aşağıdaki iki ilkeyi temel alan yeni bir paket yöneticisinin yazılmasına karar verilmiştir:

    Kurulum ve yapılandırma birbirinden ayrı iki görevdir. Kurulum, yalnızca programların kurulumu, güncellenmesi ve kaldırılması esnasında iş görürken, yapılandırma hem kurulumda hem de çalışan sistemde söz konusudur. Bu ayrı görevleri sorumluluk sınırları belirlenmiş ayrı araçların yerine getirmesi uygundur. Uludağ projesi için yapılandırma işlerini yürütecek araç ÇOMAR'dır. PİSİ bu görevleri ÇOMAR'a devredecektir.
    Paket meta bilgileri ile paketin derlenme ve kurulumunu yöneten betikler iç içe geçmemelidir. Varolan paket yöneticilerinde paket tanımlama dosyaları kod ile bilginin birbirine karıştığı, araçlarla işlemesi, içinden bilgi çıkarılması zor, net ve kesin tanımlanmamış biçimlerdedir.

[dschzz]

Many Thanks, saygili!

Sadly I cannot read the Turkish text and the google translator obviously cannot read it much better, it produces something that makes very little sense. But knowing the English text helped some. From what I understood from both texts together:
- Dropping PISI seems to mean dropping COMAR, too. That's something I did not know.
- It seems that when PISI & COMAR were developed, the workload of maintaining repositories was not taken into account
- "Test builds" can be done by developers and administrators. IMHO that's a big advantage over dpkg/synaptic.

I need to learn more...

[jasperodus]

Hello,

Here is the Pisi link. Why they have choosen.

http://www.brighthub.com/computing/linux/articles/52774.aspx

The author states that PCLinuxOS uses the same package-management system (rpm) as its 'parent' (ultimate, that is) Red-Hat. I do not know the inner workings of package-management systems, but PCLinuxOS does not use 'straight' rpm - it uses apt-rpm, a bit of a hybrid, in which apt tools have been grafted onto rpm. And PCLinuxOS also uses synaptic.

(I had intended to raise this point as part of separate, more general post which I have ideas for).

In making his conclusion, the author says: "By picking the best features from each package manager, PISI is ready to be implemented in the mainstream distributions."

Any thoughts about this last comment?


p.s. Oh dear, I see that I have been a bit messy with my first sentence. I had better say: Red-Hat>Mandrake>PCLinuxOS.

[dschzz]

...
The author states that PCLinuxOS uses the same package-management system (rpm) as its 'parent' (ultimate, that is) Red-Hat. I do not know the inner workings of package-management systems, but PCLinuxOS does not use 'straight' rpm - it uses apt-rpm, a bit of a hybrid, in which apt tools have been grafted onto rpm. And PCLinuxOS also uses synaptic.

From hurriedly reading some docs I figured that apt-rpm is just a port of the apt user interface to work with an underlying RPM repository. If that's correct, one would see something that looks like a Debian package management while it "secretly" uses RPM. The package formats are different but obviously near enough to each other so that this can be done. 

(I had intended to raise this point as part of separate, more general post which I have ideas for).

In making his conclusion, the author says: "By picking the best features from each package manager, PISI is ready to be implemented in the mainstream distributions."

Any thoughts about this last comment?

Well... I believe that the other package formats seem to not provide enough information to be properly processed with PISI.

If that's wrong, it would be possible to build an automatic converter from .deb to .pisi (or/and .rpm to .pisi), and that's is - all problems solved, Pardus would not (necessarily) loose it own repositories, it would "just" gain the ability to add Debian repositories to Pardus repositories. That would be so great that I doubt it is possible, otherwise somebody must have had this idea before.

If that's not wrong, the loss of Pardus-(.pisi-)repositories could not be avoided and the next best thing would be to rework the internals of PISI so that it can process .deb packages (and not .pisi packages anymore). That would most likely be a lot of work and take a lot of time. And most likely some of the features of PISI must be dropped anyway. In the meantime, dpkg/apt/synaptic would be already there... I don't think that users would come back to PISI after a year or more and after they got used to dpkg/apt/synaptic.

[saygili]

@dschzz

The problem is without Pisi and Comar why do we need Pardus? There is Debian,Ubuntu Mint etc.

Why we are still discussing this Debian I really do not understand.

We will have Pardus (pisi,comar,yali,tasma,kaptan) or creature?

I do not want creature. If Pardus will end let it end like this. But I (personally) do not want to see useless .deb or .rpm package based distro.

If these distrubitons are really good then we would not discuss Pardus here.

Please lets focus to pisi and Pardus.

Linux does not mean the richness of repository as I said. Stability, ease of use, configuration. Some how we are still living with Pardus despite its repo is not as rich as debian.

Best Regards,

Many thanks all of you friends. I hope I could explanin my feelings without breaking anything.

[Rob]

Main reason many like Pardus, is that it just works, and does a great job as a reliable OS for doing what you want without fear of the Windoze BSOD and random freezeds that are still around in 7

[PhiX]

And now I have a sort of technical question:
What were the reasons that Pisi was developed at all?

Simple by Design

The most obvious part of PiSi is its simplicity. From its svn like console interface pisi-cli to its package building mechanism, it is very easy to grasp the inner workings and use effectively. It is so simple that when the first PiSi source code was revealed with some example source packages, it only took twenty-minutes for someone to contribute a new package to Pardus. And there were no documentation about the build system whatsoever. Xml based source packaging system is so intuitive and easy to grasp that it almost needs no documentation.

Actually this was intentionally made that way. When you look at the current package managers, you can see that the variety of the tools for managing and the various package building helper tools, create an unnecessarily complicated system.

The first complication comes from the different tools that combined make the desired package management possible. The so called native package managers (DPKG, RPM, etc.) does the house keeping jobs and above them there exists many other wrapper tools (apt, dselect, urpmi, yum, aptrpm, etc.) for mainly handling the dependency resolution, package selection and installation issues.

But the main complication and difficulty comes from the various build helper tools, ad-hoc source specification formats and build scripts. The learning curve is steep for new developers.

PiSi architecture is quite different from traditional designs. Every functionality, related to package management like installing, building, dependency solving, fetching, validating, repository management is in the core of PiSi. On the other hand, package configuration is clearly separated from package management system and is delegated to COMAR. The configuration system is not limited with preremove or postinstall scripts; it is a much more advanced system that makes all the installed packages to be configured in a unique way by using the same COMAR API. A package may provide a configuration service script to be used as a configuration interface for itself. Configuration of packages can be done remotely or locally.

Traditionally, build scripts of packages are shell scripts. We think shell is ideal for simple tasks, like batch run of a series of commands with maybe some conditionals but nothing more. Shell scripting is awkward. It needs many other additional helper tools with their own syntax and usage. Moreover, debugging and maintenance costs are high.

When it comes to a complex task like building a package, you need conditional operations, string manipulations, iteration over series of data, and many other operations where you can all get from higher scripting languages also with additional advantages. For those reasons we have chosen Python.

Python is the choice of Pardus in all of the distribution's core components for its simplicity, flexibility and easing the maintenance advantages. YALI (Yet Another Linux Installer), the simple, fast and the pretty installer of Pardus [4]; Package Manager (the graphical frontend of PiSi) [5]; Pardusman, the automatic Live or Install Pardus distribution CD/DVD creator that only needs for the packages to be selected [6]; Buildfarm, the software that creates the binary repositories from the corresponding source repositories [7]; all use PiSi internally. A complicated system like buildfarm is written in a 1-2 weeks of time with Python and PiSi api.

Build System of PiSi

Overview

PiSi build system consists of a meta information file called pspec.xml and the actual build script file called actions.py. These are the main files to build a binary package. There can be other optional files like patches and COMAR scripts.

Following is a sample source package from the current stable branch of Pardus:
openssh
 |__ comar
 | |__ service.py
 |
 |__ files
 | |__ openssh-4.3_p1-chroot.patch
 | |__ scp-resume.sh
 | |__ sshd.pam
 |
 |__ actions.py
 |
 |__ pspec.xml
pspec.xml and actions.py files are in the root directory of the package. files directory is optional and may contain the patches or additional files to the package. Another optional directory, comar, contains COMAR scripts for integrating package with the rest of the system; all to be registered to COMAR daemon. COMAR needs an article of its own so we will not focus on the COMAR related parts.

Following is the content of a sample binary package from the current stable branch of Pardus:
Archive: joe-3.5-2-2.pisi
Length Date Time Name
-------- ---- ---- ----
2047 11-10-06 02:41 metadata.xml
11465 11-10-06 02:41 files.xml
263332 11-10-06 02:41 install.tar.lzma
-------- ------- 276844 3 files
Automatically generated metadata.xml and files.xml files are in the root directory of the binary package. metadata.xml file holds the meta data information related to binary package that are extracted from pspec.xml file. files.xml file holds detailed information about all the files that are contained in the install.tar.lzma like hash, type, size, user, group and mode informations of the files.

Build Scripts

PiSi build scripts are divided into three phases: setup, build and install. setup is the configuration phase prior to build. Build phase is the actual compilation phase. And the install phase is where the build output is installed to the destination system. Depending to the package, setup and build phases may be optional.

Most of the build automation software systems [8] that are used by the source archives of the packages, roughly need these steps to install the software but they differ from each other. So what PiSi does is to provide an underlying and unified framework for the known build systems and make the packagers' lives easier. This framework is called ActionsAPI and is included with PiSi package as an independent module. The actions.py scripts use this module to build packages.

Following is the actions.py script of joe package as an example:
#!/usr/bin/python
# -*- coding: utf-8 -*-
#
# Copyright 2006 TUBITAK/UEKAE
# Licensed under the GNU General Public License, version 2.
# See the file http://www.gnu.org/copyleft/gpl.txt.

from pisi.actionsapi import autotools

def setup():
    autotools.configure()

def build():
    autotools.make()

def install():
    autotools.install()

[PhiX]

Package Specifications

Build scripts are not enough to create a package. There are some other necessary informations used in the build phase and also some meta data that is needed to be placed in the output package. We decided to separate the meta data from the build scripts and placed them into a file called pspec.xml. Pspec.xml holds build related informations like runtime and buildtime dependencies of a package, path and sha1sum of the source archive, patches to be applied and other meta data informations like packager information, description, summary, homepage of the software project and changelog info of the package, etc. We decided to put the data into a XML file instead of using an ad-hoc text format. This makes it easier to process and to write independent tools for various purposes. It is also much more structured and readable.

Following is the pspec.xml file of joe source package as an example:
<?xml version="1.0" ?>
<!DOCTYPE PISI SYSTEM "http://www.pardus.org.tr/projeler/pisi/pisi-spec.dtd">
<PISI>
    <Source>
        <Name>joe</Name>
        <Homepage>http://sourceforge.net/projects/joe-editor</Homepage>
        <Packager>
            <Name>İsmail Dönmez</Name>
            <Email>ismail@pardus.org.tr</Email>
        </Packager>
        <License>GPL-2</License>
        <IsA>app:console</IsA>
        <Summary>Joe text editor.</Summary>
        <Summary xml:lang="tr">Joe metin dzenleyicisi</Summary>
        <Description>Joe is a small text editor with sytax highlighting.</Description>
        <Archive sha1sum="aeee6bb71ed1e9b9c9a2a64d8e078a06245957e5" type="targz">
        http://easynews.dl.sourceforge.net/sourceforge/joe-editor/joe-3.5.tar.gz
        </Archive>
        <BuildDependencies>
            <Dependency>ncurses</Dependency>
        </BuildDependencies>
    </Source>
    <Package>
        <Name>joe</Name>
        <RuntimeDependencies>
           <Dependency>ncurses</Dependency>
        </RuntimeDependencies>
        <Files>
            <Path fileType="executable">/usr/bin</Path>
            <Path fileType="config">/etc</Path>
            <Path fileType="man">/usr/share/man</Path>
        </Files>
    </Package>
    <History>
        <Update release="2">
            <Date>2006-11-10</Date>
            <Version>3.5</Version>
            <Comment>Stable update</Comment>
            <Name>İsmail Dönmez</Name>
            <Email>ismail@pardus.org.tr</Email>
        </Update>
        <Update release="1">
            <Date>2006-01-08</Date>
            <Version>3.3</Version>
            <Comment>First release.</Comment>
            <Name>İsmail Dönmez</Name>
            <Email>ismail@pardus.org.tr</Email>
        </Update>
    </History>
</PISI>
One other virtue of using XML format is that it is possible to easily divide packages by defining more Package tags into a pspec.xml file.

Components and Categories

PiSi defines two relations to identify a package: Components and Categories. We can say a x package is part of y component and that x package belongs to z category. With components we have a ``partof'' relation and with categories we have an ``isa'' relation.

Most of the time the directory hierarchy of the source package also gives us the component of the package, except for some rare corner cases. On the other hand, category of the package is explicitly defined in the pspec.xml file with an IsA tag.

We can use the previous given example, joe package to show these relations. Source package joe is under applications/editors/joe directory in our source repository. [9]There we can see that the component of the joe package is ``applications.editors''. The category of the package is defined in the pspec.xml as ``app:console''.

We can use the components to create a minimal system with all the packages under those components installed. A component is an installable entity for PiSi. You can install the ``system.base'' component to have a minimal base system and the ``desktop.kde.base'' component to have a minimal desktop environment.

Currently the category info is used by Package Manager[5] that has an option to show only the packages that belong to ``app:gui'' category.

What PiSi Brings

Dependency Resolver

As in all advanced package systems, PiSi has its own dependency resolver. It is designed to be within PiSi from the beginning and so different from DPKG and RPM, not done with wrapper tools. It is based on a topological sort algorithm.[10] Kept as simple as possible to be able to work as fast and efficient as possible. It is adequate for our needs and we do not plan to create a beast out of it. It currently allows for the build system to provide the dependent and conflicting packages with relative versioning informations.

Scenarios

One of the difficult parts of developing a package system is to reproduce the reported bugs to figure out what went wrong. But it is not always easy to reproduce the problems. Or sometimes you figure out a possible scenario that resulted as the reported bug, but you have to make sure that it is that case. And to make sure you fixed it, you have to have a way to reproduce the bug easily to test your fixes. PiSi ScenarioAPI is just for that purpose. By using the ScenarioAPI you write scenario scripts that ends as the bugs reported. So by writing scenario scripts, you have easily reproducable cases. You can add many packages as you like for the test cases. The packages will automatically be created on runtime of the script.

ScenarioAPI uses PiSi's ability of working with a different system root. Every command may take an optional -D parameter that points to a destination directory that resembles a chroot system for PiSi. The directory may be an empty one. When PiSi sees there is no database environment in the directory, it creates one to work with. So the scenario scripts run in an isolated space. Image creation tools also uses this feature.

Following is a sample scenario script taken from the PiSi trunk that tests when the conflicting package removals happen. According to the bug report, removal happens before any package is fetched. But it should be done after fetching all the packages and before starting to upgrade to the fetched packages.
from pisi.scenarioapi.scenario import *

XORG = "xorg"
QT = "qt"
XORG_SERVER = "xorg-server"
XORG_VIDEO = "xorg-video"
XORG_FONT = "xorg-font"

let_repo_had(XORG)
let_repo_had(QT, with_dependencies(XORG))
let_pisi_had(XORG, QT)

def run():
    repo_added_package(XORG_VIDEO, with_conflicts(XORG))
    repo_added_package(XORG_FONT, with_conflicts(XORG))
    repo_added_package(XORG_SERVER, with_conflicts(XORG), with_dependencies(XORG_VIDEO, XORG_FONT))
    repo_version_bumped(QT, with_removed_dependencies(XORG), with_added_dependencies(XORG_SERVER))
    repo_updated_index()
    pisi_upgraded()
Source and Binary Repositories

PiSi supports both source and binary repositories.

The source packages of Pardus are developed at our svn repositories.[11] The svn repositories are also used as source repositories.

The binary packages are kept at our binary repositories. [12] When new package releases are committed; the Buildfarm creates binary packages from source repositories and moves them to the corresponding binary repositories. Buildfarm package queue is managed manually by repository administrators.

The source and binary repositories are represented by their index files named pisi-index.xml. Both created by PiSi's index command executed from the root of the repository. The index command creates a pisi-index.xml file out of that repository tree. Adding and using new repositories to PiSi is as simple as:
pisi add-repo contrib http://paketler.pardus.org.tr/contrib/pisi-index.xml.bz2
pisi add-repo pardus-2007-sources http://svn.pardus.org.tr/pardus/2007/pisi-index.xml.bz2
Building and Emerging of Packages

In the example above, we have added a source repository named pardus-2007-sources. The given repository names are arbitrary.

After adding a source repository we have many options to work with the source packages. First of all, since we have all the source package informations from a repository, we can simply build any package by giving only the name of the package as in:
# pisi build kiki
The build command will fetch the original source archive, the patches provided by the source package, additional files and COMAR scripts to a temporary location. If there are missing build dependencies to satisfy, PiSi will try to install them. After building, the binary kiki-x-y-z.pisi package will be created.

The build process is divided into multiple steps. For example, you may not want to build binary package but just to see the source code of the software provided with that package. Or you may want to work on that code and try multiple builds until you are finished and then continue to other steps of the binary package creation operation. The build command steps are: fetch, unpack, setup, build, install, package. Fetch step just fetches the source tarball of the package. Unpack step extracts the archive and then applies any existing patches. Setup, build and install are the actual building steps. The last step, package, is the one that creates the binary ''.pisi'' package. As an example to unpack a package, you do:
# pisi build --unpack kiki
The source packages are extracted and compiled under /var/pisi directory. The output binary package will be written to the current working directory.

The good thing is that you don't need a source repository to work with the source packages. It is possible to build a package by providing only the local path or the remote url of a spec file without having any source repository added to PiSi database.

Here is an example to build the same package by providing only its remote url:
# pisi build http://svn.pardus.org.tr/pardus/devel/applications/games/kiki/pspec.xml
One other feature of PiSi is its ability to emerge source packages from the source repositories. By emerging, PiSi automatically downloads the buildtime and runtime dependencies of the package. If they do not exist in any binary repository, PiSi also tries to emerge those missing dependencies from the source repositories. PiSi does not need the whole source repository to be checked out or downloaded. Because a source repository is represented by the index file that also contains all the dependency informations and building a package by its remote url is possible, for emerging a package, you only need to add the source repository of the package to PiSi database.

Here is an example to emerge a package:
# pisi emerge kiki
LZMA Compressed Packages

LZMA, short for Lempel-Ziv-Markov chain-Algorithm, is a data compression algorithm. We decided to use LZMA compression in our package format for its greater compression ratio than gzip and bzip2. It is about %30 better than gzip and %15 better than bzip2. [13]

To give a more concrete example: Pardus 1.0 stable release was using gzip compression in PiSi packages. With all our efforts to put all the necessary packages to satisfy the needs of a desktop user, we were only able to put a total of 335 packages. But now in Pardus 2007, by using LZMA compression within PiSi package format, there comes 641 packages with the installation CD. When all the packages that are in Pardus 1.0 CD are extracted to the destination system, it takes 1.891 GB of disk space and that is 3.043 GB of disk space for Pardus 2007.

The package format is a zip archive. This makes it possible to reach the metadata and COMAR files of the package faster by using the standard tools. Under the zip archive, there exists install.tar.lzma file that contains the actual files of the package to be extracted to the system. A sample pisi package content is as following:
Archive:
 /var/cache/pisi/packages/openssh-4.5_p1-13-10.pisi
  Length     Date   Time    Name
 --------    ----   ----    ----
     1357  10-22-06 21:16   comar/service.py
     6824  11-10-06 11:59   metadata.xml
     7803  11-10-06 11:59   files.xml
   388881  11-10-06 11:59   install.tar.lzma
 --------                   -------    404865                   4 files
Non-Root Installations

PiSi package comes with a COMAR management script manager.py that is registered to COMAR's database when PiSi's own package is installed. By using this script's services over COMAR, it is possible to do root privileged package operations. Package Manager, the PiSi frontend uses these services to install, remove, upgrade packages or add/remove new repositories to PiSi database. The authorization is done by the COMAR daemon. By extending these services, it will also be possible to remotely manage the package system of any machine.
i18n Support

The xml spec file format makes it possible to provide translations of the description and summary of the packages to other languages. We are aware of the problem that just updating a translation itself would need a release increase and therefore a package update. i18n support is important so we will try to balance that problem by waiting the next release of the package with an actual update need. We are planning to create a delta pisi package format in the future that can also help with this problem. We decided to keep all the related info in the corresponding packages for its ease of maintenance purposes. Description and summary tags of the packages are exported to a standard pot file from the repository and accommodated to our Pardus translation statistics page.[14] Translated po files then are merged with the corresponding source packages in the repository. These operations are done with our repository translation scripts. [15]

4  Near Future

One of the important things PiSi lacks right now is package signing and validation. We are currently working on this and expect to have an implementation soon.

One other feature we are going to work on is delta pisi package format. We decided not to use a binary diff tool like xdelta. LZMA does its job well on compression part so we are working on the possibility of creating packages only with affected or changed files.

There are suboptimal usages of Berkeley DB. PiSi should have been faster in some certain database operations. This is also planned to be fixed in the next major release.

A sandbox support for PiSi is also planned. There are two ways to sandbox a build script within user context: Overriding glibc functions with LD_PRELOAD or intercepting system calls with ptrace. We decided to go with the ptrace, cause former makes it cumbersome to pass Python variables between builder and build scripts. We considered Subterfugue[16], but although it is extremely flexible with the Python system call hooks, it isn't fast enough for production use in a build farm. Thus we wrote catbox[17], a small sandboxing module for PiSi. It is completely written in C, and designed to do just required features for package management. Not all features are completed yet, but basic sandboxing works and will be incorporated with PiSi in the future.

5  Conclusion

One of the design goals of PiSi was easy development and maintenance of the packages. We think that PiSi had reached that goal in its early releases that made us possible to create that many packages in such a short time with so far no problems.

Pardus tries to stand out with its new and brave approaches in the problematic areas of Linux distributions. With PiSi and COMAR architecture we created a system that now stands on its feet. The next step is to evolve the system with so many things that are possible to do with the provided infrastructure and to gain new developers by capturing their attention with what we see in Pardus.

[PhiX]

How PiSi handles dependency: (http://svn.pardus.org.tr/uludag/trunk/pisi/doc/dependency.pdf) Dependency resolution in package management systems have a significance in that they are the key to providing system stability and internet upgrades. This document shows how PiSi resolves dependency problems.