[Nix-dev] Stackage Support Will Be Discontinued

Thu Jun 9 11:20:45 CEST 2016

It might make sense to create an external repo (nix-hackage?) with the
stackage releases and it's own release.nix. That way it can evolve
independently from nixpkgs and not clobber the main repo. It can also offer
it's own binary cache as a service to haskell developers. You might even be
able to join forces with the stackage guys on that front.

In the main nixpkgs, add a link to the latest version of the nix-hackage.
Then remove all the packages from haskellPackages; remove all the libraries
and place the executable programs in the normal pkgs/ hierarchy. If all the
programs are pre-compiled users won't have to download nix-hackage. That
way it keeps nixpkgs small and executables can evolve independently from
the stackage releases (I definitely had times where I wanted the latest
version of `stack`).

On Thu, 9 Jun 2016 at 09:17 Oliver Charles <ollie at ocharles.org.uk> wrote:

> I pin my Haskell packages by using fetchFromGitHub with a specific nixpkgs
> revisions, and then import the result. The only downside is the Haskell
> packages linking against things like OpenSSL as you say wouldn't get
> patched.
>
> On Wed, 8 Jun 2016, 8:58 p.m. Teo Klestrup Röijezon, <teo at nullable.se>
> wrote:
>
>> So there will no longer be a way to pin Haskell dependencies? That's a
>> bit annoying. I can understand the desire to keep security-critical
>> packages like OpenSSL and user-facing tools like git-annex up to date, but
>> at the same time there are many non-critical dependencies that I wouldn't
>> want to go back and patch my one-off deployments for updates of.
>>
>> The old way is/was certainly not perfect, but at least it provided a
>> mostly-stable target that I could pretty much forget about after deployment.
>>
>> On 8 June 2016 at 13:34, Peter Simons <simons at nospf.cryp.to> wrote:
>>
>>> 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 at lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>>
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160609/71fe4ab4/attachment-0001.html>