On the Haskell Platform

[Heinrich Apfelmus]

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 
> http://people.debian.org/~nomeata/platform.html
 >
> [..] 
> 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 
part:

A. Always support the latest version of a dependency (compiler, library, 
...), i.e. the upper bounds of my version constraints have to match the 
latest stuff.

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 
Platform).


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com