[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