Hi, Am Sonntag, den 13.05.2012, 21:36 +0200 schrieb Heinrich Apfelmus:
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.
yes, always supporting the latest version available on hackage is a good idea. If everyone would be doing that I would not have to send „please upgrade your package to mtl-2.1 / transformers-0.3“ mails now. Having the lower version include other common versions (i.e. the latest platform release and/or versions found in distribution releases you care about) is a good idea as well.
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.)
Well, for a distro package user, he is expected to first blame the distro (unless he is knowledgable enough to know that a certain bug/problem is caused by upstream). Not all users know that, though, and it does not help if there is a conflict between a distribution-provided package and code taken from somewhere else.
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.
I would suggest to exclude the broken versions from your dependency. cabal-install users will then hopefully get your package built against an older, non-buggy version.
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.)
This is a general problem in the Haskell ecosystem that not all build-dependencies combinations can be tested. For a few targets, you can test it using different ~/.cabal directories or probably some of the recent cabal-enhancing tools (cabal-dev et. al.), which I don’t know myself. Or just do the RERO-principle and assume things work until someone complains. But you are right in that things are not so easy to get perfectly right :-) Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata@joachim-breitner.de