[Nix-commits] SVN commit: nix - r34059 - nixpkgs/trunk/pkgs/top-level
Author: simons Date: Fri May 11 13:04:28 2012 New Revision: 34059 URL: https://nixos.org/websvn/nix/?rev=34059sc=1 Log: haskell-packages: downgrade 'mtl' and 'transformers' in GHC 7.4.1 environment to fix build errors 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'. 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. 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. Modified: nixpkgs/trunk/pkgs/top-level/haskell-packages.nix Modified: nixpkgs/trunk/pkgs/top-level/haskell-packages.nix == --- nixpkgs/trunk/pkgs/top-level/haskell-packages.nix Fri May 11 12:16:09 2012(r34058) +++ nixpkgs/trunk/pkgs/top-level/haskell-packages.nix Fri May 11 13:04:28 2012(r34059) @@ -157,8 +157,8 @@ zlib = self.zlib_0_5_3_3; # 7.4.1 ok HTTP = self.HTTP_4000_2_3; # 7.4.1 ok text = self.text_0_11_2_0; # 7.4.1 ok -transformers = self.transformers_0_3_0_0; # 7.4.1 ok -mtl = self.mtl_2_1_1; # 7.4.1 ok +transformers = self.transformers_0_2_2_0; # 7.4.1 ok +mtl = self.mtl_2_0_1_0;# 7.4.1 ok random = self.random_1_0_1_1; # 7.4.1 ok cabalInstall = self.cabalInstall_0_14_0;# 7.4.1 ok alex = self.alex_3_0_1; # 7.4.1 ok ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] [Nix-commits] SVN commit: nix - r34059 - nixpkgs/trunk/pkgs/top-level
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 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] GHC 7.4.1 and Haskell Platform (was: [Nix-commits] SVN commit: nix - r34059 - nixpkgs/trunk/pkgs/top-level)
Hi Andres, 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. obviously, there are plans to release a new version of Haskell Platform. I don't doubt that -- all I meant to emphasize is that this release hasn't happened yet. Generally speaking, there is a strong interest to conform to HP, because it provides stability and predictability. We deviate from HP only when there is a very compelling reason to do so. Another interest of ours, however, is that we want to provide a usable system, i.e. a package database that people can actually install and use. Those two interests conflict. The upcoming HP standard is probably going to mandate use of mtl 2.x and transformers 3.x -- so we have an interest in using those packages in haskellPlatformArgs_future. On the other hand, configuring GHC 7.4.1 to use those packages right now breaks a lot of other packages, some of which are extremely popular, like monad-par, graphviz, Pandoc, and everything else that depends on those. This gives us an incentive *not* to update mtl and transformers right now. Now, in order to decide whether we should update mtl today or not, we have to weigh Haskell Platform conformance against usability. I don't think we've ever made a decision to support 7.4.1 already. You seem to see this differently. Yes, exactly. I've been supporting GHC 7.4.1 for quite a while. I use it myself, and I support it in the sense that I don't commit any updates without testing first how they affect the 7.4.1 environment. I use monad-par in several of my projects, and I also heavily depend on Pandoc. The mtl update breaks those two packages, leaving me with a non-functional working environment! That situation is very unpleasant for me. Given the fact that the new HP standard hasn't been released yet, I feel that having a usable system is more important than conformance. That judgment is probably going to change once a new HP release has been made, but until then I'd rather have a system that actually works. Take care, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
