[Nix-dev] [Nix-commits] SVN commit: nix - r34059 - nixpkgs/trunk/pkgs/top-level

Andres Loeh ksnix at andres-loeh.de
Fri May 11 15:33:55 CEST 2012


> The new versions of mtl and transformers break many important packages, such as
> monad-par, graphviz, pandoc, and all other packages that depend on any of those.
> This situation causes serious problems for me, because I depend on some of those
> packages for my daily work. IMHO, it is an overreaction to have all those builds
> fail, because some day in the future a new version of Haskell Platform *may* be
> released that *may* recommend the latest versions of 'transformers' and 'mtl'.

You make it sound like I'm inventing things. Sure, it hasn't been
released yet, and there's been some discussion about these packages in
particular. Nevertheless, it's very likely that it happens, and it's
likely that it happens this month.

> As
> long as those changes have such profound negative effects on our packages, those
> upgrades should be deferred. This approach seems consistent with the way we've
> handled these matters things in the past, too. For example, we happily break
> conformance with older versions of HP, when those changes are beneficial for
> users. In other words, we have usually valued usability over strict conformance
> before, and IMHO that is a sensible policy.

While I think that's ok for old versions of GHC, I don't think we
should deviate from the "current" platform if at all possible.

> I agree that it's nice to test what kind of trouble these upgrades cause, but I
> don't believe that 'trunk' is the right place to perform those tests. The breakage
> these changes cause affect users who rely on Nixpkgs to provide a stable working
> environment.

Well, the only reason ghc-7.4.1 is currently in nixpkgs is for
testing. It's clearly marked as low priority. If people are using it
already, it's at their own risk. I don't think we've ever made a
decision to "support" 7.4.1 already. You seem to see this differently.
I think the solution here is to create two separate sets of defaults,
one aimed at platform conformance, and one aimed at maximal
compatibility with existing packages.

Cheers,
  Andres


More information about the nix-dev mailing list