Experiments in Haskell Packaging

January 2, 2012

[This article was posted on the Haskell Cafe mailing list today.]

The http://justhub.org Haskell distribution for Enterprize Linux (RHEL/CentOS 5 & 6) is now live.

The distribution deviates from current practice. When you upgrade to a new Platform from justhub.org you add the new platform to your Haskell infrastructure rather than replacing the old platform with a new one.

Why?

  • Stability: Enterprise Linux places a strong emphasis on stability and updating packages should not break things. (This has provided some challenges for us as RHEL 5 is still using GCC  4.1.2 and Binutils 2.17.50.)
  • Flexibility: Different projects will in general need to work with different versions of the platform and toolkits and upgrade according to their own schedules. I believe Haskell’s strong-typing sharpens the need for this. Production projects will need to upgrade according to their own schedules while other projects will want to stay up-to-date. In general when you check out a source tree you want to build with the tools and libraries that it has been tested with and move on according to the project’s timetable.
  • Sandboxes: The same mechanism for managing the multiple toolkits and platforms can be adapted to provide an integrated sandbox utility. The logic that dictates that projects have different tool-chain requirements applies to the user packages too. (‘Handbox’ doesn’t really work so we use Hubs instead.)
  • Package Deletion: The infrastructure can also be expanded to complete the package management tools with package removal and garbage collection of library code.
  • The Catalogue: All of the GHC releases can be added as they become available.

In general the distribution works just like any other – after an upgrade invoking ‘ghc’ without any other configuration will invoke the compiler for that latest platform, which should behave as it would on any other (working) distribution.

But after an upgrade:

  • any projects configured to work with specific tool chains and libraries will continue undisturbed;
  • you can create a new hub based on the new platform and experiment with it on newly-checked-out source tree without disturbing an existing working tree (or just swap the hub into an existing work tree and back out again if things don’t work out);
  • even on release of a new version of a package (or if you want to experiment with your existing packages) you can easily duplicate an existing hub and delete, upgrade and add packages on a topic branch.

Of course ‘serious developers’ have been doing this with home-brew infrastructure for ever. Nevertheless I have found doing it with well-integrated tools to be quite liberating.

It might also help new users to make the transition to serious developers more quickly.

Thoughts anyone?

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: