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