[Nix-dev] Stackage Support Will Be Discontinued

[Anthony Cowley]

Peter Simons writes:

> 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
>

I know you didn't ask for feedback, but I think the announced change is a significant mistake.

(To define terms, I'll refer to version components as LTS-major.minor, though this deviates from the typical Haskell PVP.)

First, if the top priority is receiving bug fixes, then keeping an LTS-4, LTS-5, LTS-6, etc. that tracks the most recent minor version makes sense; dropping all prior LTS releases does not. You say, "Stackage does not "maintain" any of its LTS releases," but the minor releases are precisely the offered maintenance. So, if nixpkgs cannot accommodate the file size of the Stackage definitions, we could at least keep one for each major release.

Major versions indicate breaking changes; keeping around older versions offers reasonable hope that a project's shell.nix could define an environment in which the project can be built. Furthermore, there is no reason a new LTS-5 release can not be issued after the first release of LTS-6. This would likely only happen in the event of a serious bug, but having versions at least admits this possibility. Moreover, the cultural prominence of Stackage means that the need for security fixes to older versions can actually be promulgated because Stackage has users.

Second, we must contend with the typical conflation between critical security fixes and less consequential changes. For a modest application, specifying a particular Stackage release is a concise way of freezing Haskell dependencies. Perhaps a dependency's minor-version change has unintended effects that should have prompted a major version bump; or perhaps you just don't want to recompile things so often. What you want is a stable set of packages.

Perhaps nixpkgs users should regularly script cabal2nix to manually freeze haskellPackages, but then nixpkgs users lose the cultural benefits of Stackage and are instead operating with a semi-arbitrary snapshot of a single person's definition of a package set.

Your first link demonstrates a Nix problem, but the decision announced here just shifts the burden to every user. A typical Stackage definition is about 70KB; that the corresponding Nix definitions require nearly 10x that space is unfortunate, but I had expected a Nix solution to this issue rather than giving up on versions altogether.

Anthony