On the Haskell Platform

[Joachim Breitner]

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 at joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  Jabber-ID: nomeata at joachim-breitner.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120513/105f111d/attachment.pgp>