Smaller is not always better

Recently, I noticed that building packages from AUR–especially big packages–started taking a long time. makepkg was spending a lot of time in compressing files. After a bit of searching, I found that thsi was because Arch Linux switched from gz to xz as a compression format.

In principle, this move is a good step. xz takes 30% less space than gz. So, while installing binary packages, you download less bits at the cost of running your cpu at a higher speed for some time. However, when it comes to building packages from AUR, xz is horrible. xz superior compression comes at the cost of a drastic increase in the compression time (see here for a realistic test case). When building a package from AUR, you spend about 10 times more time to create the binary package using makepkg, and then spend three times more time to uncompress the package using pacman. All that to save 30% of space in /tmp/ that will be deleted at the next reboot.

I did not like this trade-off, so I have decided to revert to gz for the packages that I build on my system (and also for context-minimals-git package that I maintain). If you also want to do that, edit /etc/makepkg.conf and change




If you only want to change the compression format for a particular package, add the above line in the PKGBUILD.

Pacman, don’t eat my disk space

I run Arch Linux on my laptop that has a 100GB disk with a 15GB partition for /, a 15GB partition for /opt and the remaining 70GB for /home. Recently I ran out of disk space on /. First I thought that this was due to a huge browser cache (in opera, my temporary download directory is set to /tmp/opera/downloads which can get really big). Clearing up the /tmp did not help, and I went on a wild goose chase of figuring out which directory was hogging disk space. The culprit: /var/pacman/cache/pkg.

pacman, the arch package manager, keeps a cache of all packages it downloads! Over the last year or so that I have been running Arch, this directory had become huge, taking over 5GB of space. I do not want a cache of all package that I ever downloaded. I bit of hunting through the man pages revealed the right options.

pacman -Sc

which removes all the uninstalled packages from the cache. After that, /var/cache/pacman/pkg is at a bearable 2.5GB. I also learnt that if I ever need more disk space, I can run

pacman -Scc

which will remove all packages from pacman cache.

Haskell on Arch Linux

I was a happy user of Ubuntu until a few months ago when GHC 6.10 was released. Ubuntu still had GHC 6.8.2. Posts on haskell-cafe told that Arch Linux had support for latest GHC, and support for over 700 Haskell libraries. Since I had started using Haskell for a few projects, I decided ot check Arch linux out. After a long weekend of struggling through the installation and learning more about linux than I intended to know, I had all my usual programs up and running on Arch. Once I discovered AUR, I had the latest versions of almost everything. Or so I thought.

The first glitch was that Arch does not install the profiling version of the libraries. I asked around on #haskell, and I was told, that I should use cabal to install the profiling version of libraries. I did not want to have conflicting versions of libraries, so I uninstalled a few libs from the Arch repositories, and manually installed them using cabal.

And now I figured out that Haskell libraries are not so up-to-date on AUR. For example, new versions of monte-carlo and gsl-random were released more than a week ago, but AUR still has the old versions. So, I decided to install them using cabal.

After having used Arch for about two months, I am not convinced that it has a good support for Haskell. The only good thing is that it comes with a version of cabal that can upgrade itself. (From what I remember, the ubuntu version of cabal could not upgrade  itself, and I had to install cabal by hand). But once cabal is updated, it is much more convenient to use cabal than the Arch repositories. Arch is a great distribution and I  like the rolling release philosophy, but its support for Haskell is mediocre at best.

Most programming languages come with their own tools for installing libraries (CPAN for perl, gem for ruby, cabal for Haskell, and now even texlive has a tool for updating packages). I do not think that it is worth the effort to port packages to distribution repositories. Simply using the language’s tool for installing libraries is much simpler and much easier to maintain.