On the Haskell Platform
apfelmus at quantentunnel.de
Sun May 13 21:36:40 CEST 2012
Joachim Breitner wrote:
> Heinrich Apfelmus wrote:
>> Clearly, this must be a fake Haskell Platform, because the latest real
>> Haskell Platform is still at GHC 7.0.4 at the time of this writing.
>> Unfortunately, my principle 1 is now rendered moot.
> The problem with packaging the platform is that distributions have a
> one-version-per-package policy, so we can not always have exactly the
> version present in the latest platform, e.g. because other packages
> require a newer version, or just because the old version is too old and
> buggy and our users want newer versions. Therefore, we take the liberty
> to diverge a bit. You can see the current status for Debian on
> From a distro point of view I can only say: We made policies and
> decisions that lead to us not being able to provide up-to-date libraries
> _and_ the latest (or even all) platform versions, so this problem will
> likely stay around for a while.
I see. Thinking about this, it appears to me that the only way to meet
the "one-version-per-package" constraint is the following approach on my
A. Always support the latest version of a dependency (compiler, library,
...), i.e. the upper bounds of my version constraints have to match the
B. If desired, support older versions of a dependency by adjusting the
lower bounds of my version constraints.
This way, my package can never be blamed when it fails to install;
rather, "the blame" falls on the user for not upgrading his system.
(Package management is probably best seen as a "blame game". Scenario:
"This package fails to install, who is to blame?" Usually, the user can
only assign responsibility to the author of the package, even though the
latter may not have direct control over the problem. Of course, the
overall goal of package management is to route responsibility to the
right person who can fix it.)
However, this approach is not without problems.
The first problem is this: what happens if the newer version of my
dependency has a bug? This happened to me in the case of GHC 7.2 and now
also in the case of wx-0.90 . Unfortunately, neither waiting for an
upstream fix (GHC-7.2) nor working on an upstream fix myself (wx-0.90)
will help: I have to implement a workaround in my own package if I want
to keep it usable for everyone who has already installed the buggy
dependency. I tried to depend on an older version, but doesn't fly with
the approach above.
The second problem is that the lower bounds will tend to be higher than
necessary. The thing is that once I install the new dependency on my
machine and develop a new feature in my package, I can no longer test
whether my package still works with the old version. That would require
me have both versions of my dependency installed at the same time, which
is very tricky with the "one-version-per-package" assumption. Unable to
test the old version, I cannot, in good conscience, include a dependency
on the old version. (However, doing so is not too bad for me, because I
can deflect "the blame" in case it doesn't work.)
> What we can offer, though, is to package your software. A „complete
> Haskell beginner“ should maybe use distro-packaged libraries in the
> first place, precisely because the distribution takes care of these
> issues for him.
That's a good idea. Unfortunately, it doesn't help with the issue at
hand (new dependency has a bug, old dependency requires old Haskell
More information about the Libraries