Fellow Haskell Hackers, once the LTS 7.x package set comes out, I intend to make the following changes in "master":
- All haskell.packages.lts.* package sets will disappear. - haskellPackages will loosely follow the most recent LTS release, where "loosely" means that we'll honor the mandated version bounds for libraries but tend to ignore them for executables. Nixpkgs has shipped every single LTS Haskell version ever released as well as an up-to-date copy of the Stackage Nightly package set for the last 9 months or so, and during that time we've gained insights that suggest this practice is an ineffective use of our resources [1]. 1. It's pointless to distribute LTS Haskell version x after the release of version x+1. Stackage does not "maintain" any of its LTS releases. Rather, the Stackage volunteers compile a list of package versions, test and verify them to the best of their abilities, release that list, and then they never touch it again. For example, there won't be any update to LTS Haskell 5.4. That update comes in the form of a new package set called LTS 5.5. So if LTS 5.4 happens to recommend a package that has a serious problem, then that problem will remain there forever. So what is the point of distributing LTS 5.4 after the release of 5.5? Apparently, Stackage intends LTS 5.5 to *replace* the previous version, so isn't that what we should do, too? Furthermore, a major release like LTS Haskell 5.x receives no updates either after LTS 6.x has comes out, so by the same logic there is no point in distributing LTS 5.x after LTS 6.x has become available. Contrary to what the name suggests, LTS versions have no guaranteed lifetime or support cycle. Stackage does not offer any "long-term support" in the sense distributions use the word. "Releases" are merely names for tested snapshots of a project that essentially follows a rolling release model. 2. Following LTS strictly may deprive us of important security updates. Whether a package update goes into a minor LTS release or not depends on whether that update increments the first or second segment of its version number. 6.1.1 -> 6.1.2 will make it, but 6.1.1 -> 6.2 won't. That is a pretty good rule based on the assumption that all LTS contributors follow it, which -- as you will have guessed -- is not the case. The tool git-annex, for example, uses version numbers that have only two levels: <api>.<date>. Due to that scheme, git-annex updates aren't considered for minor LTS releases, which means that security relevant fixes don't reach LTS users until the next major LTS release [2]. 3. Stackage Nightly is not a stable package set. Our main package set, haskellPackages, corresponds to Stackage Nightly. We made that choice assuming that it would guarantee us a good mixture of a stable user experience on one hand and an up-to-date packages on the other. Recent experience has shown, however, that Stackage Nightly *will* break some of its packages knowingly on the occasion: the Nightly package set recently moved to GHC 8.0.1, but a handful of libraries and applications blocked that (desirable) update. At that point one would expect people to postpone the compiler update, but what happened instead is that the troublemakers were simply removed from Stackage [3]. Now, that is a perfectly legitimate decision to make, it just had the unfortunate side effect of breaking all those builds for users of Nixpkgs in the process, so arguably following Stackage Nightly with our main package set might be a bad idea. 4. Stackage does not provide a stable users experience for Nixpkgs. Stackage releases come out only after a complete test build of all packages has succeeded. Unfortunately, those tests don't always catch all issues we might run into, because we compile packages in a different environment. Stackage builds on Travis-CI using 64-bit Ubuntu Linux with static linking. Our builds run on all kinds of Linuxes and on Darwin, we support 32 bit platforms, and we link everything with shared libraries by default. This means that some of our builds fail even though they succeed in Stackage [4]. Now, we usually report these issues to Stackage and on some occasions they've made an effort to fix the issue, but on other occasions their response was, essentially, "works for me". That leaves us in an odd place, because we're nominally following Stackage (and our users rely on getting exactly those builds that Stackage promises), but at the same time we have no choice but to deviate from Stackage because the builds they want us to do just don't work. As such, it's a good idea to use Stackage as a *recommendation* for our package set, but we cannot expect to be 100% compliant to Stackage and provide a stable user experience at the same time. Best regards, Peter [1] https://github.com/NixOS/nixpkgs/issues/14897 [2] https://github.com/fpco/stackage/issues/1465 [3] https://github.com/fpco/stackage/commit/cb54d78615c0e154913007e9437ff30de6e13661 [4] https://github.com/fpco/stackage/issues/1453 _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev