Creating packages for Pardus Linux with pisido
Pardus Linux is a relative newcomer to the Linux scene. Version 1.0 was released at the end of 2005, and since then, the project started using version numbers that remind us of what Mandriva uses for some time. So, the latest stable version is 2011.2, which means it's the second release for 2011. Pardus Linux is a distribution sponsored and developed by the Scientific & Technological Research Council of Turkey. It's a easy to use distribution, with a series of unique tools like Pisi (Packages Installed Successfully as Intended), which is the package manager. We will not give you a Pardus review, instead we'll assume you have the distro already installed and running and we'll tell you about a tool named PiSiDo. This tool enables you in a graphical, user-friendly way, to create pisi packages starting from source code. So for this article we'll assume only that you have Pardus installed. If you still have some questions after reading this article please try our new LinuxCareer Forum.
2. Using Pisi
I don't know how others are but I, for one, whenever I use a new tool, my reflex is to type "man $command". After I installed Pardus Linux (very nice installer, by the way), since I already knew that it uses pisi as the package manager, I typed "man pisi" only to be dissapointed by the lack of a manual page. I hoped I could get some more help from the graphical front end package manager, but it segfaulted on me every time. So I finally discovered help with
$ pisi -h
so I could get some basic help at least. It would be unfair to compare Pisi or Pardus with other older package management systems/distributions like Fedora or Debian, so, especially since this Python-based package manager isn't as complex as yum/rpm or apt/dpkg, I settled for the help dialog. On the other hand, I think Pardus could use some translators, since it has a wiki and usually the information is pretty easy to find, but sometimes you're stuck reading a page in Turkish.
Long story short, the commands offered by pisi are as follows:
usage: pisi [options] <command> [arguments] where <command> is one of: add-repo (ar) - Add a repository blame (bl) - Information about the package owner and release build (bi) - Build PiSi packages check - Verify installation clean - Clean stale locks configure-pending (cp) - Configure pending packages delete-cache (dc) - Delete cache files delta (dt) - Creates delta PiSi packages disable-repo (dr) - Disable repository emerge (em) - Build and install PiSi source packages from repository enable-repo (er) - Enable repository fetch (fc) - Fetch a package graph - Graph package relations help (?) - Prints help for given commands history (hs) - History of pisi operations index (ix) - Index PiSi files in a given directory info - Display package information install (it) - Install PiSi packages list-available (la) - List available packages in the repositories list-components (lc) - List available components list-installed (li) - Print the list of all installed packages list-newest (ln) - List newest packages in the repositories list-pending (lp) - List pending packages list-repo (lr) - List repositories list-sources (ls) - List available sources list-upgrades (lu) - List packages to be upgraded rebuild-db (rdb) - Rebuild Databases remove (rm) - Remove PiSi packages remove-repo (rr) - Remove repositories search (sr) - Search packages search-file (sf) - Search for a file update-repo (ur) - Update repository databases upgrade (up) - Upgrade PiSi packages
Two elements are of interest here: the delta command and the build command. Pisi uses delta packages by default, which saves bandwidth, which means that when upgrading (up), only binary differences between the installed and available packages will be installed. Next, as the name implies, build allows you to build your own packages. I think it's kinda cool that one can use the same tools for installing as well as for building packages. Now, as stated earlier, it took me a while to find documentation on how to build my own packages with pisi. The process requires some XML knowledge, plus some Python knowledge if the build process is complicated and there are postinstall operations to make, for example. It looks a lot like RPM packaging to me, except that there you have to know specfile syntax and that's that. Here...it's a different story. So instead of showing you how to write XML or Python for building with pisi, we'll take advantage of PiSiDo.
3. Getting and using PiSiDo
As one can see, there is a pisi package available on Sourceforge, which you can install thusly:
$ mkdir ~/build
$ cd ~/build
[download package here]
# pisi it pisido-2.0a-11-p11-x86_64.pisi
We created the build directory in the user's home because we will need it anyway when starting PiSiDo, since you will be asked for a workspace where the built packages will be saved.
What's important for us, based on the screenshot above, is the left-center part of the window, where you will have to enter data, and the rightside down part, where you will get to decide what actions PiSiDo will perform and to what point, so you can tell it to only unpack, build, install, etc. You'll see every step of the build process as it happens in the terminal-like window. So let's say we're not content with wget being at version 1.12 in 2011.2 stable and we want 1.13. Since we have a build directory we can use that as the location to download the source code in.
$ cd ~/build
$ wget -c http://ftp.gnu.org/gnu/wget/wget-1.13.tar.gz
Some of the fields in the screenshot above are pretty self-explanatory, but we'll take it step by step: we used 'wget' as the name, at archive type we used compressed, not URL, since the .tar.gz is already downloaded. We left the dependency fields empty to see what will happen, entered GPLv3+ in the license field, component 'system' and we will let you fill in the remaining three fields. Except for the dependency-related fields and the type, everything else is mandatory, and so is the fact that you'll need a source archive with a configure script. That is unless you want to change the template type (cmake, Python...). When I tried to build a source (written in C) .tgz with no configure script, it failed (see screenshot below), which actually makes a lot of sense.
Now in the upper right part, press the '+' sign to add a new history entry (mandatory as well) and fill in the necessary fields, as you can see in the example below:
So that's about it! In the Build Commands section select "Only Package" and Up To Install", which will basically create a .pisi file in your build directory, but not install it, and just press the button corresponding to "Only Package". If you don't have autotools, automake and the like installed, PiSiDo will take care of that for you, but if your package requires an external dependency, you will get an error.
I also got an error, since wget depends on some GNU TLS headers, so I filled in as a Build Dependency the gnutls-devel package. I was asked to confirm the installation of that package then the build process started normally and I was notified that my fresh wget package is in the build directory. Now that your wget 1.13 package is ready, we recommend uninstalling the older version to avoid potential issues.
If you take some time to play around with PiSiDo you will see that it's also pretty easy to apply a patch to an existing source and create a new package with a new version from it.
I see this utility as a very practical tool, since package creation on many distributions is a somehow tedious job. Maybe more Linuxes should look at PiSiDo and try to help their users create packages for their favorite software more easily. All in all, Pardus and its' tools looked like a fun experience, even though I'm more into "geeky" distributions. Certainly worth checking out once in a while.