[Haskell-cafe] Experiments in Haskell Packaging

[Chris Dornan]

[I am sorry for if get two copies of this -- no sign of the first copy.]

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

The distribution deviates from current practice. When you upgrade to a
new Haskell Platform 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?

Chris