Re: [Nix-dev] Stackage Support Will Be Discontinued

[Teo Klestrup Röijezon]

Fair enough, that seems like a reasonable solution.

On 11 June 2016 at 18:31, Benno Fünfstück 
wrote:

> Teo Klestrup Röijezon  schrieb am Mi., 8. Juni 2016 um
> 21:58 Uhr:
>
>> 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.
>>
>
> There should be still a way to do this. I don't think stackage supports
> needs to be removed from `hackage2nix` or `cabal2nix`, so you can still
> simply generate your own `hackage-packages.nix` and include that with your
> project to pin the hackage snapshot.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Benno Fünfstück]

Teo Klestrup Röijezon  schrieb am Mi., 8. Juni 2016 um
21:58 Uhr:

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

There should be still a way to do this. I don't think stackage supports
needs to be removed from `hackage2nix` or `cabal2nix`, so you can still
simply generate your own `hackage-packages.nix` and include that with your
project to pin the hackage snapshot.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Игорь Пашев]

2016-06-08 22:58 GMT+03:00 Teo Klestrup Röijezon :
> 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.


There is a way. I experimented with a custom derivation which:
1. Has fixed Hackage snapshot metadata (tarball)
2. Initializes cabal from that tarball, instead of downloading the "recent".
3. Builds in normal `cabal install` way

Yes, it rebuilds every dependency every time.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Mathnerd314]

On Wed, Jun 8, 2016 at 5:34 AM, Peter Simons  wrote:
> Fellow Haskell Hackers,
>
> once the LTS 7.x package set comes out, I intend to make the following
> changes in "master":
>
>  - 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.

8 months ago, I suggested using the latest versions of all packages
[1]. Apparently, that policy is too simple to receive any discussion.

I don't see any point in "loosely following" LTS releases, when
following the latest Hackage version is equally as prone to breakage
(i.e., very infrequently).

But such breakage does occur, so I propose an extension:
* hackage-packages.nix foo is always the latest Hackage version of the
package; but it will also contain old versions like foo_1_0_2
* Jailbreak all packages by default (because Hackage bounds tend to be
overly conservative), but allow whitelisting bounds on a per-package
basis
* If foo only works with bar version 1 instead of the latest bar, then
foo will depend on bar_1 instead of bar in hackage-packages.nix
* If the latest version of a package does not work on GHC version X,
then configuration-ghc-X.nix should override it to a version that does
work, or mark it as broken if no such version exists.
* If a package update breaks almost all dependencies, then the package
can be overridden to an earlier version in configuration-common.nix
(so all packages will use the old version)

People who want to follow a Stackage release can... use Stack. Stack
has been designed for this purpose and supports all the upgrade
patterns that people would like to follow. On the other hand, Stack
does not support using Haskell libraries from Nix [2][3], so there is
no point in doing anything in nixpkgs beyond providing an executable
Stack binary. If Stack does add support for downloading precompiled
Haskell libraries, it will be using their own infrastructure. Perhaps
this would be implemented with a separate repository and Hydra
instance, as zimbatm suggests, but I think it would probably not use
Nix at all.

-- Mathenrd314

[1] http://article.gmane.org/gmane.linux.distributions.nixos/18306
[2] https://github.com/commercialhaskell/stack/issues/1683
[3] 
https://github.com/commercialhaskell/stack/blob/master/doc/nix_integration.md
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Peter Simons]

Hi Thomas,

 > Anthony's complaint is:
 >
 >   The choice to discontinue Stackage support makes Nixpkgs
 >   significantly less useful to some of our users.

which packages do you (or Anthony) compile in old LTS package sets today
that you would be unable to build in haskell.packages.lts? If there is any
specific problem, then I am sure we can find a solution.

If the problem is that you (or Anthony) want full Stackage support,
period, then I'm afraid you'll have to do that yourselves because I see
little value in generating those ~90 untested, unmaintained package sets
any longer and do not wish to continue doing that.

IMHO, a solution that makes the entire LTS Haskell package set available
in an extra repository to those who want it sounds like a good compromise,
but don't feel strongly about that subject. In any case, I don't want to
be involved much in such an endeavor for the reasons outlined in the
posting that started this thread.

Best regards,
Peter

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Rok Garbas]

Hi,

I'd like to reinforce Thomas'es writing and I'd like to add that as it
is important how we do things, it is also important how we reach the
consensus. I think any of us want only what produces best results.

Nix being a tool that works on many platforms with many different
languages, different setups, makes this even harder since not
everybody uses Nix the same way. And of-course changing is always
hard, so please be patient, it takes time to change somebodies
opinion, but doing this through conversation works best in the long
term.

It would be nice list down (or copy paste into this tread) pros/cons
and costs of keeping multiple LTS versions around.

Maybe having separate ``nixpkgs-haskell`` where all LTS versions leave
and only include latest LTS in nixpkgs would be a good enough
compromise.



On Fri, Jun 10, 2016 at 1:42 PM, Thomas Tuegel  wrote:
> Hi Peter and Anthony,
>
> On Thu, Jun 9, 2016 at 4:04 PM, Peter Simons  wrote:
>> Hi Anthony,
>>
>>  >> [What is] a concrete use case that works for you today but that
>>  >> won't work after LTS-4 has been dropped?
>>  >
>>  > Someone who has a project that works with package versions in LTS-4,
>>  > but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to
>>  > LTS-4 in their shell.nix for haskell packages.
>>
>> Oh, but you can absolutely do that! You can extend the set of available
>> packages to your heart's content and you can compose package sets that
>> provide any combination of versions as you please. The Haskell
>> infrastructure in Nix gives you that ability.
>
> Let me remark on this non-sequitor. Of course Anthony or I or anyone
> else could always extend or fork Nixpkgs to do whatever we want! I
> don't think anyone with experience in open source software needs this
> to be pointed out to them. That's obviously not Anthony's complaint,
> which is rather
>
> The choice to discontinue Stackage support makes Nixpkgs significantly
> less useful to some of our users.
>
> It seems disingenuous to pretend that some other complaint is being
> made, for the sake of summarily dismissing that complaint. As
> *volunteer* distribution maintainers, we are free to consider or
> disregard complaints at will; there is no need to misrepresent what
> people are saying.
>
> It is completely legitimate to take the position that the benefit (to
> our users like Anthony) of keeping Stackage does not outweigh the
> resource cost to Nixpkgs or the technical cost of finding a more
> efficient way to include those packages. This is obviously the
> position that the Haskell infrastructure and Nixpkgs maintainers have
> reached. Stating outright that they will not be swayed saves our users
> time and frustration because they can immediately seek solutions
> outside Nixpkgs.
>
> Regards,
> Thomas
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev



-- 
Rok Garbas
http://www.garbas.si
r...@garbas.si
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Daniel Peebles]

Yeah. I think there's a tough balance to strike in OSS between feedback and
gratitude, and most of us have been on both wrong sides of it in the past.

Peter is putting all this work in for free and has almost single-handedly
been responsible for drawing a sizable chunk of the Haskell community
(including me) to the Nix world. That is awesome. He's also obviously free
to pour his free time into whichever direction he thinks is best for the
project (or not put any time in at all, obviously).

At the same time, feedback is important to all creative processes, even
when critical. What we have here is two prominent haskellers saying that
the changes that Peter is proposing will make the system less useful to
them, and that they predict it'll also make the system less useful to
others with similar workflows. I think that feedback, even if critical, is
extremely valuable, and should factor into Peter's decision. I realize it
can be tough to separate out the negativity from the gratitude but we're
all in this boat together and if people disagree, it's because they all
want the project to succeed.

Anyway, most of us are experienced in open source work and saying "you can
just fork it" is roughly equivalent to a dismissive wave of the hand in
this context.

I see a few possible outcomes here:

   1. Peter is swayed by Anthony and Thomas's arguments, and decides to
   keep (parts of?) stackage support around.
   2. Peter is swayed by their arguments, but still doesn't use stackage
   himself and with limited free time is unwilling to maintain support
   himself. He and other interested parties figure out a good way to split
   responsibilities so that people who care about stackage can still maintain
   a first-class (i.e., non-forked) experience for it, and he can focus on
   other workflows that interest him more.
   3. Peter is unswayed by their arguments and doesn't think stackage
   belongs in mainline nixpkgs, effectively forcing some sort of forked
   workflow (or Anthony and Thomas and others like them to do their Haskell
   work outside of Nix)
   4. Everyone gets pissed off and thinks nobody appreciates/understands
   their work/feedback and walks away from this discussion feeling drained and
   less willing to contribute to Nix.

I'd personally prefer #1 or #2. Let's do our best to avoid #4 though?


On Fri, Jun 10, 2016 at 7:42 AM, Thomas Tuegel  wrote:

> Hi Peter and Anthony,
>
> On Thu, Jun 9, 2016 at 4:04 PM, Peter Simons  wrote:
> > Hi Anthony,
> >
> >  >> [What is] a concrete use case that works for you today but that
> >  >> won't work after LTS-4 has been dropped?
> >  >
> >  > Someone who has a project that works with package versions in LTS-4,
> >  > but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to
> >  > LTS-4 in their shell.nix for haskell packages.
> >
> > Oh, but you can absolutely do that! You can extend the set of available
> > packages to your heart's content and you can compose package sets that
> > provide any combination of versions as you please. The Haskell
> > infrastructure in Nix gives you that ability.
>
> Let me remark on this non-sequitor. Of course Anthony or I or anyone
> else could always extend or fork Nixpkgs to do whatever we want! I
> don't think anyone with experience in open source software needs this
> to be pointed out to them. That's obviously not Anthony's complaint,
> which is rather
>
> The choice to discontinue Stackage support makes Nixpkgs significantly
> less useful to some of our users.
>
> It seems disingenuous to pretend that some other complaint is being
> made, for the sake of summarily dismissing that complaint. As
> *volunteer* distribution maintainers, we are free to consider or
> disregard complaints at will; there is no need to misrepresent what
> people are saying.
>
> It is completely legitimate to take the position that the benefit (to
> our users like Anthony) of keeping Stackage does not outweigh the
> resource cost to Nixpkgs or the technical cost of finding a more
> efficient way to include those packages. This is obviously the
> position that the Haskell infrastructure and Nixpkgs maintainers have
> reached. Stating outright that they will not be swayed saves our users
> time and frustration because they can immediately seek solutions
> outside Nixpkgs.
>
> Regards,
> Thomas
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Thomas Tuegel]

Hi Peter and Anthony,

On Thu, Jun 9, 2016 at 4:04 PM, Peter Simons  wrote:
> Hi Anthony,
>
>  >> [What is] a concrete use case that works for you today but that
>  >> won't work after LTS-4 has been dropped?
>  >
>  > Someone who has a project that works with package versions in LTS-4,
>  > but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to
>  > LTS-4 in their shell.nix for haskell packages.
>
> Oh, but you can absolutely do that! You can extend the set of available
> packages to your heart's content and you can compose package sets that
> provide any combination of versions as you please. The Haskell
> infrastructure in Nix gives you that ability.

Let me remark on this non-sequitor. Of course Anthony or I or anyone
else could always extend or fork Nixpkgs to do whatever we want! I
don't think anyone with experience in open source software needs this
to be pointed out to them. That's obviously not Anthony's complaint,
which is rather

The choice to discontinue Stackage support makes Nixpkgs significantly
less useful to some of our users.

It seems disingenuous to pretend that some other complaint is being
made, for the sake of summarily dismissing that complaint. As
*volunteer* distribution maintainers, we are free to consider or
disregard complaints at will; there is no need to misrepresent what
people are saying.

It is completely legitimate to take the position that the benefit (to
our users like Anthony) of keeping Stackage does not outweigh the
resource cost to Nixpkgs or the technical cost of finding a more
efficient way to include those packages. This is obviously the
position that the Haskell infrastructure and Nixpkgs maintainers have
reached. Stating outright that they will not be swayed saves our users
time and frustration because they can immediately seek solutions
outside Nixpkgs.

Regards,
Thomas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Profpatsch]

On 16-06-09 05:25pm, Anthony Cowley wrote:
> I think that telling users to stick to a single version of nixpkgs and take
> responsibility for cherry-picking individual security and bug fix commits to
> all Haskell and system libraries they depend on is the worst job a package
> management system can do while still calling itself a package manager. I do
> appreciate that you find such a setup appealing, so I'll say no more as this
> is solely your call.

You are free to maintain a repository that keeps all those LTS versions.
The means to do that are freely available and I guess Peter Simons would
happily teach you how to use them. :)

-- 
Proudly written in Mutt with Vim on NixOS.
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
May take up to five days to read your message. If it’s urgent, call me.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Anthony Cowley]

Peter Simons writes:

> Hi Anthony,
>
>  >> [What is] a concrete use case that works for you today but that
>  >> won't work after LTS-4 has been dropped?
>  >
>  > Someone who has a project that works with package versions in LTS-4,
>  > but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to
>  > LTS-4 in their shell.nix for haskell packages.
>
> Oh, but you can absolutely do that! You can extend the set of available
> packages to your heart's content and you can compose package sets that
> provide any combination of versions as you please. The Haskell
> infrastructure in Nix gives you that ability.
>
>
>  >>> You are removing that opportunity because it hasn't been used yet.
>  >>
>  >> I don't intend to remove any "opportunities" here. All I want to remove
>  >> is some 850,000 lines of untested, unmaintained code from the Nixpkgs
>  >> repository. [...]
>  >
>  > If it's 850,000 lines of code, then that really seems like a Nix
>  > issue. If the point here is to declare bankruptcy and tell people to
>  > use stack which is able to refer to multiple versions of packages,
>  > then let's call it that.
>
> I have a hard time assigning meaning to vague terms like "removing
> opportunities" and "declaring bankruptcy" in a technical conversation. I
> am sorry, I just don't see how to these kind of things make a compelling
> argument for distributing old LTS releases in Nixpkgs.

I truly don't understand why this is hard for you to understand, so we are of a 
mind on this misunderstanding! There must be a language barrier or different 
understanding of what breaking version changes are between us.

>  > [A team using Nix today] can refer to LTS-5 in nixpkgs, and not need
>  > to make any changes to adopt LTS-6 until they are ready. I know that
>  > should a problem emerge with LTS-5, a project using stack has a good
>  > chance of benefiting from a new Stackage release. I know that after
>  > the changes you are making, the team using LTS-5 in nixpkgs will not
>  > have a working environment until they address any of the 5->6
>  > breaking changes.
>
> This is true only if we assume that the team depending on LTS-5 updates
> their copy of Nixpkgs to a version that breaks their code. But they
> don't have to. They can use a version of Nixpkgs that works for them
> until they're comfortable addressing the issues caused by an update.
> Also, these changes I'll be making show up only in the branch we dub
> "unstable". The release-16.03 branch, for example, has LTS-5 and will
> continue to have it until all eternity.
>
> You realize that Nix allows you to override the contents of the Nixpkgs
> version you're using without actually editing that version, right? You
> can stick to any given version of Nixpkgs, but if an update of, say
> libuuid, comes out that you'd like to have, then you can override only
> that particular package in configuration.nix or ~/.nixpkgs/config.nix
> without ever touching Nixpkgs itself. This gives you a stable package
> plus selected, hand-picked updates. IMHO that is an awesome mechanism
> for stable deployments.

I think that telling users to stick to a single version of nixpkgs and take 
responsibility for cherry-picking individual security and bug fix commits to 
all Haskell and system libraries they depend on is the worst job a package 
management system can do while still calling itself a package manager. I do 
appreciate that you find such a setup appealing, so I'll say no more as this is 
solely your call.

Anthony
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Peter Simons]

Hi Anthony,

 >> [What is] a concrete use case that works for you today but that
 >> won't work after LTS-4 has been dropped?
 >
 > Someone who has a project that works with package versions in LTS-4,
 > but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to
 > LTS-4 in their shell.nix for haskell packages.

Oh, but you can absolutely do that! You can extend the set of available
packages to your heart's content and you can compose package sets that
provide any combination of versions as you please. The Haskell
infrastructure in Nix gives you that ability.


 >>> You are removing that opportunity because it hasn't been used yet.
 >>
 >> I don't intend to remove any "opportunities" here. All I want to remove
 >> is some 850,000 lines of untested, unmaintained code from the Nixpkgs
 >> repository. [...]
 >
 > If it's 850,000 lines of code, then that really seems like a Nix
 > issue. If the point here is to declare bankruptcy and tell people to
 > use stack which is able to refer to multiple versions of packages,
 > then let's call it that.

I have a hard time assigning meaning to vague terms like "removing
opportunities" and "declaring bankruptcy" in a technical conversation. I
am sorry, I just don't see how to these kind of things make a compelling
argument for distributing old LTS releases in Nixpkgs.


 > [A team using Nix today] can refer to LTS-5 in nixpkgs, and not need
 > to make any changes to adopt LTS-6 until they are ready. I know that
 > should a problem emerge with LTS-5, a project using stack has a good
 > chance of benefiting from a new Stackage release. I know that after
 > the changes you are making, the team using LTS-5 in nixpkgs will not
 > have a working environment until they address any of the 5->6
 > breaking changes.

This is true only if we assume that the team depending on LTS-5 updates
their copy of Nixpkgs to a version that breaks their code. But they
don't have to. They can use a version of Nixpkgs that works for them
until they're comfortable addressing the issues caused by an update.
Also, these changes I'll be making show up only in the branch we dub
"unstable". The release-16.03 branch, for example, has LTS-5 and will
continue to have it until all eternity.

You realize that Nix allows you to override the contents of the Nixpkgs
version you're using without actually editing that version, right? You
can stick to any given version of Nixpkgs, but if an update of, say
libuuid, comes out that you'd like to have, then you can override only
that particular package in configuration.nix or ~/.nixpkgs/config.nix
without ever touching Nixpkgs itself. This gives you a stable package
plus selected, hand-picked updates. IMHO that is an awesome mechanism
for stable deployments.

Best regards,
Peter

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Anthony Cowley]

Peter Simons writes:

> Hi Anthony,
>
>  > I draw a distinction between newer minor versions obsoleting old ones
>  > for purposes of bug fixes vs. for purposes of freezing packages.
>
> I am sorry, but I don't understand that distinction. In your original
> response you suggested that dropping old LTS major releases like LTS-4
> from Nixpkgs would reduce your ability to use Nix, i.e. it would make
> Nixpkgs less useful to you than it is today. I have a hard time seeing
> how what might be the case, so I wonder whether you'd mind explaining to
> me a concrete use case that works for you today but that won't work
> after LTS-4 has been dropped?

Someone who  has a project that works with package versions in LTS-4, but 
hasn't yet been upgraded to LTS-5 or 6. They can simply refer to LTS-4 in their 
shell.nix for haskell packages.


>  > The Stackage design is such that they *can* release bug fixes for
>  > older versions to help their users.
>
> Yes, I totally agree. Once Stackage starts releasing updates for older
> LTS versions, it's a completely different situation and then carrying
> around older LTS major releases would actually make sense.
>
>
>  > You are removing that opportunity because it hasn't been used yet.
>
> I don't intend to remove any "opportunities" here. All I want to remove
> is some 850,000 lines of untested, unmaintained code from the Nixpkgs
> repository. If there is a compelling use case for that code, then let's
> talk about it! At the moment, however, the cost / benefit ratio of
> keeping all those package sets around strikes me as bad, really, and I
> don't think we should keep distributing that code unless there's a real
> benefit to the effort.

If it's 850,000 lines of code, then that really seems like a Nix issue. If the 
point here is to declare bankruptcy and tell people to use stack which is able 
to refer to multiple versions of packages, then let's call it that.

>  > As companies adopt Stackage package sets, they will have applications
>  > in production that they, A) really want bug fixes for; and B) do not
>  > want to keep on the hackage treadmill by following new releases. If a
>  > bug is found in an LTS-5 package within the next few months, a stink
>  > will be raised.
>
> I think everyone agrees that we *want* LTS-5 updates to come out even
> after the release of LTS-6. Whether that is actually going to happen or
> not, however, is speculation and neither you nor me can possibly know.

I know that today a team using Nix can refer to LTS-5 in nixpkgs, and not need 
to make any changes to adopt LTS-6 until they are ready. I know that should a 
problem emerge with LTS-5, a project using stack has a good chance of 
benefiting from a new Stackage release. I know that after the changes you are 
making, the team using LTS-5 in nixpkgs will not have a working environment 
until they address any of the 5->6 breaking changes.

>  >> In Nix, we [freeze dependencies] by tagging a specific version of
>  >> Nixpkgs and sticking to that. Not only will that freeze the Haskell
>  >> dependencies, but it will also freeze all other dependencies, too.
>  >
>  > This is a big step backwards. You object that Stackage has not yet
>  > used their existing mechanism for releasing bug fixes for older
>  > Haskell libraries, and respond by promoting a mechanism that admits
>  > no bug fixes for any software at all.
>
> I have no idea what you are talking about. Nix offers a myriad of
> different ways to cherry pick updates into a stable version of the
> package set.

Here's a quote that perhaps states it more clearly, "In Nix, we can solve these 
things by tagging a specific version of Nixpkgs and sticking to that. Not only 
will that freeze the Haskell dependencies, but it will also freeze all other 
dependencies, too."

I saw on IRC that you use stack for some Haskell development and nixpkgs for 
other things, so I don't think there's much point in continuing this as it 
clarifies your intentions for the nixpkgs design. I have been using nix, and 
more recently nixpkgs, in place of stack, but if you are not then we simply 
have different goals and the issues I raise are not relevant.

Anthony
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Peter Simons]

Hi Anthony,

 > I draw a distinction between newer minor versions obsoleting old ones
 > for purposes of bug fixes vs. for purposes of freezing packages.

I am sorry, but I don't understand that distinction. In your original
response you suggested that dropping old LTS major releases like LTS-4
from Nixpkgs would reduce your ability to use Nix, i.e. it would make
Nixpkgs less useful to you than it is today. I have a hard time seeing
how what might be the case, so I wonder whether you'd mind explaining to
me a concrete use case that works for you today but that won't work
after LTS-4 has been dropped?


 > The Stackage design is such that they *can* release bug fixes for
 > older versions to help their users.

Yes, I totally agree. Once Stackage starts releasing updates for older
LTS versions, it's a completely different situation and then carrying
around older LTS major releases would actually make sense.


 > You are removing that opportunity because it hasn't been used yet.

I don't intend to remove any "opportunities" here. All I want to remove
is some 850,000 lines of untested, unmaintained code from the Nixpkgs
repository. If there is a compelling use case for that code, then let's
talk about it! At the moment, however, the cost / benefit ratio of
keeping all those package sets around strikes me as bad, really, and I
don't think we should keep distributing that code unless there's a real
benefit to the effort.


 > As companies adopt Stackage package sets, they will have applications
 > in production that they, A) really want bug fixes for; and B) do not
 > want to keep on the hackage treadmill by following new releases. If a
 > bug is found in an LTS-5 package within the next few months, a stink
 > will be raised.

I think everyone agrees that we *want* LTS-5 updates to come out even
after the release of LTS-6. Whether that is actually going to happen or
not, however, is speculation and neither you nor me can possibly know.


 >> In Nix, we [freeze dependencies] by tagging a specific version of
 >> Nixpkgs and sticking to that. Not only will that freeze the Haskell
 >> dependencies, but it will also freeze all other dependencies, too.
 >
 > This is a big step backwards. You object that Stackage has not yet
 > used their existing mechanism for releasing bug fixes for older
 > Haskell libraries, and respond by promoting a mechanism that admits
 > no bug fixes for any software at all.

I have no idea what you are talking about. Nix offers a myriad of
different ways to cherry pick updates into a stable version of the
package set.

Best regards,
Peter

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Peter Simons]

Hi Anthony,

 > I know you didn't ask for feedback [...].

I'm always happy to get feedback!

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

You seem to be saying that keeping an old major release like LTS-4
around would somehow help us receive more bug fixes, but I can't see how
that would be true. According to git://github.com/fpco/lts-haskell.git,
the last time any LTS-4 update occurred was on 2016-01-18 -- almost half
a year ago. Surely, there have been point updates that fix bugs between
then and now, but LTS-4 does not seem to receive them, no? That is
because no-one maintains LTS-4. Stackage has moved on to LTS-5, or
rather: LTS-6 by now.

So how exactly do we receive more bug fixes by distributing LTS-4?


 > You say, "Stackage does not "maintain" any of its LTS releases," but
 > the minor releases are precisely the offered maintenance.

The thing is just that minor releases occur only for the latest major
release. LTS-6 has minor release at the moment, but LTS-5, LTS-4, etc.
do not! I agree that it would make sense to continue to distribute LTS-4
if there were further minor releases to come out for that package set.
But there won't be any. As far as Stackage is concerned, LTS-4 is dead.


 > Furthermore, there is no reason a new LTS-5 release can not be issued
 > after the first release of LTS-6.

Sure, this *could* happen and it would be great! Then we'd have a real
long-term supported package set that would be worth-while to distribute.


 > The cultural prominence of Stackage means that the need for security
 > fixes to older versions can actually be promulgated because Stackage
 > has users.

I am sorry, but I have no idea what that sentence means.


 > For a modest application, specifying a particular Stackage release is
 > a concise way of freezing Haskell dependencies.

In Nix, we can solve these things by tagging a specific version of
Nixpkgs and sticking to that. Not only will that freeze the Haskell
dependencies, but it will also freeze all other dependencies, too.


 > A typical Stackage definition is about 70KB.

Huh? That's not what I am seeing in git://github.com/fpco/lts-haskell.git:

   $ ls -lh lts-6.2.yaml
   -rw-r--r-- 1 simons users 4.7M Jun  6 11:58 lts-6.2.yaml


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

Oh, come on. I wrote a very long and detailed explanation of *why* we
give up on tracking Hackage, and to boil that whole article down to "it
was using too much disk space" is just silly.

Best regards,
Peter

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Stackage Support Will Be Discontinued

[zimbatm]

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  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, 
> 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  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: .. 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 

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Oliver Charles]

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, 
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  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: .. 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. 

Re: [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: .. 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] 

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Teo Klestrup Röijezon]

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  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: .. 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, 

[Nix-dev] Stackage Support Will Be Discontinued

[Peter Simons]

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: .. 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]