For those of you who have been hanging around in #gentoo-haskell (especially when I’m around… :p) or who have upgraded to dev-lang/ghc-6.10.4, you would probably have noticed the new haskell-updater package. This is our replacement to the venerable ghc-updater script that was packaged with previous versions of GHC.
ghc-updater is a bash script that was based long ago on python-updater. However, whilst python-updater was updated to let users use alternative package managers like Paludis or PkgCore, it wasn’t as simple to upgrade ghc-updater as we bundle it with dev-lang/ghc. So, we (meaning I :p ) decided to split off a new haskell-updater package (with a deliberate name change to avoid problems with name clashes). At first this was just going to be based off the newer versions of python-updater, but this approach was soon abandoned (I had trouble finding my way through what it was doing).
Thus, haskell-updater is unique as far as I know amongst the various app-admin/*-updater packages (well, the only two that are there are python-updater and emacs-updater :p ) in that it is written in the languages whose packages it aims to update and rebuild. Using Haskell for haskell-updater gives us several advantages over the “traditional” bash-based kludge:
- It uses our language of choice; this means we’re more likely to be interested in it and maintain it (and be able to maintain it!) in future.
- A more modular design makes it easier to split apart parts of the code rather than a one-file-fits-all bash script.
- Ability to use the Cabal library (more on why this is a good thing later).
- Speeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeed! After all, all Gentoo-ers are ricers, aren’t we? :p Seriously, haskell-updater takes roughly 2s for me to run (whilst doing more! see below), ghc-updater takes 27s and I killed python-updater after 8.5 minutes :s
- Have a piece of software written in Haskell that Don Stewart isn’t going to brag about having it available in Arch 😉
Now, haskell-updater doesn’t just find packages installed with previous versions of GHC like ghc-updater did; it also finds broken packages, making it equivalent to revdep-rebuild/reconcilio/etc. for Haskell packages (though just for libraries, since at the moment GHC creates statically-linked binaries). This has become a bigger problem in the last few years as the number of Haskell libraries has almost exploded (especially after the base library being split up). Until now, however, users have had to manually run “ghc-pkg check” and build the corresponding packages by hand (otherwise you face the dreaded Diamond Dependency Problem). However, version 1.6 of the Cabal library includes support for parsing the output of “ghc-pkg check”, so we’re able to use this to have haskell-updater find these broken packages for you as well!
haskell-updater has several other incremental advantages over ghc-updater (supports slotted packages properly; able to find packages installed with previous versions of GHC even if someone manually went and deleted the old GHC directory when they shouldn’t have, etc.). As such, we highly recommend that people install it and try it out. Note, however, that it requires one of the 6.10 series of GHC releases or higher to work (technically it doesn’t as long as you install the necessary libraries yourself; however, we’ve stated this in the ebuild to try and avoid dependency problems when upgrading GHC). With version 6.10.4, it has completely replaced ghc-updater (ghc-updater is still shipped with previous versions) as the used updating tool.
Extra features we’re considering adding in future releases:
- Allow user-defined package managers (in case of custom scripts, etc.).
- The ability to print out the command to rebuild the packages rather than actually running it.
- Detect and fix packages that didn’t get re-registered by ghc-pkg when re-building the same version of GHC (this seems to be a problem when using Paludis).
- Adding colours to the output 😉
Note that haskell-updater is not available on HackageDB like most other Haskell software; this is to avoid name-pollution there, and because we don’t think non-Gentoo users are going to be interested in it (and Gentoo users will probably have it automatically installed for them anyway).