On the Haskell Platform
mail at joachim-breitner.de
Sun May 13 22:04:40 CEST 2012
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
> 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
Or just do the RERO-principle and assume things work until someone
But you are right in that things are not so easy to get perfectly
e-Mail: mail at joachim-breitner.de
Jabber-ID: nomeata at joachim-breitner.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the Libraries