integer-gmp-1.0.1.0 needlessly requires Cabal 2

[tfausak]

integer-gmp-1.0.1.0 requires cabal-version: 2.0 for its package description even though the only feature it uses is ^>= bounds. Specifically it uses build-depends: ghc-prim ^>= 0.5.1.0 instead of build-depends: ghc-prim >= 0.5.1 && < 0.6.

Answering the questions from the contributing guidelines:

1. How and when was the maintainer for the package requiring action contacted?

   The GHC developers maintain integer-gmp. In particular HVR seems to be the one making changes to it most of the time. I opened a ticket on GHC's Trac four days ago, but the issue has been known for longer than that. I also pinged HVR on Twitter, but he has blocked me on Twitter since then.

2. If available, a link to the filed issue in the upstream issue tracker

   https://ghc.haskell.org/trac/ghc/ticket/14558
   https://twitter.com/taylorfausak/status/938243186237083649

3. If not evident from 2., how to reproduce the issue (and if known, how to fix it)

   You can reproduce this issue by doing stack --resolver nightly-2017-12-01 setup with Stack < 1.6.1.

   You can fix this issue by changing the build-depends and cabal-version in integer-gmp's package description. ghc/ghc@82aae8c
   You can also fix this issue by upgrading to Stack >= 1.6.1.

4. How critical is this, what's the impact of this breakage? E.g. how many dependent packages are affected by this? Which GHC versions are affected?

   This is extremely critical. It breaks all users of Stack < 1.6.1 using snapshots that use GHC >= 8.2. In fact, snapshots that used to work (such as nightly-2017-11-01) no longer work.
   Stack broken by latest integer-gmp commercialhaskell/stack#3624
   https://www.reddit.com/r/haskell/comments/7hs20y/how_to_fix_stack_unable_to_parse_cabal_file/

[23Skidoo]

One issue here is that Hackage prohibits revisions downgrading cabal-version, but perhaps we can add a whitelist with exceptions to that rule and put integer-gmp-1.0.1.0 on it?

[hvr]

Thank you for moving the discussion here.

This is extremely critical. It breaks all users of Stack < 1.6.1 using snapshots that use GHC >= 8.2.

As various people have already stated, Stack 1.5.1 + GHC 8.2 does not constitute an officially supported configuration (even if it happens to work accidentally). However, this can be easily fixed by stack --upgrade (which to my understanding is not hindered) and upgrading to Stack 1.6.1 which is the first Stack release that to my knowledge has proper GHC 8.2 support. Why is this not a solution?

[tfausak]

Seems like relaxing the cabal-version should be allowed in revisions.

I'm not sure what you mean by "officially supported". Who is an official in this situation? Stack 1.5.1 worked with GHC 8.2 for many months until you broke it on December 4.

Yes, Stack users can work around this problem by doing stack upgrade (not stack --upgrade). Nevertheless, this problem affects people using build plans that used to work. Also, some people are unable to upgrade to Stack 1.6.1. For example: commercialhaskell/stack#3634

[23Skidoo]

Mostly because of enterprise users who can be slow to upgrade, I think, and the fact that it breaks pre-Dec 04 snapshots that used to work. IMO, a server-side fix makes sense in this case, like the one we did for cabal-install not so long ago (see haskell/cabal#4899).

[phadej]

Enterprise users should ask for stack 1.5.2 first (

…

Sent from my iPhone

On 10 Dec 2017, at 17.03, Mikhail Glushenkov ***@***.***> wrote: Mostly because of enterprise users who can be slow to upgrade, I think, and the fact that it breaks pre-Dec 04 snapshots that used to work. IMO, a server-side fix makes sense in this case, like the one we did for cabal-install not so long ago (see haskell/cabal#4899). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[phadej]

To expand the previous:

• As I understand, stack-1.5.1 ignores cabal-version >= 2.0 packages, but as integer-gmp is a bit special: it's not ignored. So there's a bug in stack-1.5.1. Shouldn't be hard to fix, and have stack-1.5.1.1 or stack-1.5.2.
• Alternatively Cabal-2.0 support could be backported to 1.5.1 (at least parser bits). Sidenote: stack-1.6.1. doesn't support all cabal-version: 2.0 features!
• Hackage server side fix is essentially: old 00-index.tar.gz doesn't include cabal-version >= 2.0 packages. We (ab)used luckily coincidence that old cabal-installs use 00-index.tar.gz, not 01-index.tar.gz. stack however uses 01-index.tar.gz to distinguish revisions. Using revision mechanism to fix existing Stackage snapshots would be against stack philosophy!
• cabal-install has proper fix in Implement preliminary support for new forward-compat scheme haskell/cabal#4900 and related PRs, so new cabal-version specifications won't break older cabal-installs. Similar protections should be (and to my understanding is) in stack, yet broken for boot-packages.

[23Skidoo]

IMO a point release of Stack from the 1.5 branch is also a good idea, but that's a separate issue and I think we can provide a server-side fix for the users of 1.5.1 as well.

[gbaz]

I too tend to think a revision is a good way forward here, but I also share the concern that in the past, stack maintainers have argued vociferously against use of revisions. If @mgsloan or @snoyberg could sign off on this I'd feel much more comfortable.

[snoyberg]

@phadej Your understanding is incorrect, please read the blog post where I explain the situation. https://www.snoyman.com/blog/2017/12/stack-and-nightly-breakage

I am opposed to revisions, but that's a cost that's already sunk. Using it to fix this issue will be fine and introduce no further breakage, so I don't have an objection to yet another revision appearing on Hackage.

[hvr]

The irony really isn't lost on me that it's the very people that have been vehemently opposing Hackage revisions to the point of threatening to fork Hackage are the same ones equally violently demanding a Hackage revision to be made. But I'm pleased that you've come around on the merit of Hackage revisions.

While I remain convinced that from a technical POV this particular revision has little merit, I've just revised integer-gmp in a way that should accomodate your demands:

https://hackage.haskell.org/package/integer-gmp-1.0.1.0/revisions/

I would appreciate if in return you could see to it that the vendetta against us is relaxed or even better yet called off completely.

[tfausak]

That revision doesn't fix the problem because it still requires cabal-version: 2.

[gbaz]

That's all that can be accomplished with revisions. They're deliberately limited in scope.

Cf: https://github.com/haskell-infra/hackage-trustees/blob/master/revisions-information.md#what-can-revisions-change

The version can only be changed between 1.10 and 1.21, because the spec didn't change over that range.

My understanding from other discussions was that only the bounds needed to be changed, and not the version, in order for stack to work. If this isn't the case, then that's too bad, but the cabal file version is, by design, not something that can be modified too severely by the revisions process.

[23Skidoo]

That revision doesn't fix the problem because it still requires cabal-version: 2.

@snoyberg Can you confirm that? Cabal 1.24 can parse files with unsupported cabal-version as long as they don't actually use new features.

[tfausak]

Ah, you're right. I spoke too soon. That revision fixes the problem as far as integer-gmp is concerned. Thank you!

However, as leon predicted out on Trac, now base-4.10.1.0 fails.

> ./stack.exe --version
Version 1.5.1, Git revision 600c1f01435a10d127938709556c1682ecfd694e x86_64 hpack-0.17.1

> date
Sunday, December 10, 2017 11:43:01 AM

> ./stack.exe update
...

> ./stack.exe --resolver nightly-2017-12-01 setup
Unable to parse cabal file for base-4.10.1.0: NoParse "build-depends" 96

It uses ^>= constraints in three places:

build-depends: rts == 1.0, ghc-prim ^>= 0.5.1.0
build-depends: integer-simple ^>= 0.1.1
build-depends: integer-gmp ^>= 1.0.1

https://hackage.haskell.org/package/base-4.10.1.0/revision/0.cabal

[hvr]

As far as I understand it, this only affects the more recent GHC 8.2.2 based nightlies. I doubt that conservative enterprise users which haven't yet upgraded to Stack 1.6.1 would rely on such bleeding edge unstable nightly snapshots.

[23Skidoo]

IMO if 8.2.2 snapshots also used to work, even if briefly, we should also make a Hackage revision for base-4.10.1.0. However, I think it'll be fine if GHC 8.2.3 and 8.4.1 will require upgrading Stack.

[tfausak]

I agree with @23Skidoo. Some snapshots used to work. They don’t anymore. It would be nice if they could work again.

For future versions of GHC, I won’t be happy about seeing ^>= constraints, but it shouldn’t cause any problems.

(It is hard for me to follow this thread because @hvr blocked me on GitHub. I do not get notifications about his comments. Sorry for the slow reply.)

[gbaz]

I think we should consider this fixed at this point. The main issue at stake was that it broke 8.2.1 nightlies that used to work, and which people had come to rely on. In general, nightlies are allowed to be somewhat unstable. Given the heat generated thus far, and that things are in a "good enough" state, I'd rather just let things cool off and move forward.

…

On Sun, Dec 10, 2017 at 1:36 PM, Taylor Fausak ***@***.***> wrote: I agree with @23Skidoo <https://github.com/23skidoo>. Some snapshots used to work. They don’t anymore. It would be nice if they could work again. For future versions of GHC, I won’t be happy about seeing ^>= constraints, but it shouldn’t cause any problems. (It is hard for me to follow this thread because @hvr <https://github.com/hvr> blocked me on GitHub. I do not get notifications about his comments. Sorry for the slow reply.) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#120 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABEt2TEGlOujysIn_7XNbRtTVj3OSRXrks5s_CS6gaJpZM4Q8g3X> .

[tfausak]

Stackage had 6 working nightly snapshots with GHC 8.2.2 (starting with 2017-11-25) before they were broken on December 4.

[mgsloan]

Yay, thanks! Consider the vendetta on my part to be essentially gone. Still a potential sore spot, though I will try not to be so reactionary in the future. BTW, vendetta was my personal opinion, not a representation of FP Complete, please do not misrepresent my comments on twitter. That's kinda shitty.

Would still like to see cassava fixed, but I suppose that's water under the bridge. Sorry for being so intense about it. You can unblock me if you want, hvr , this is exactly the cooperation I was hoping for (though perhaps my approach for it was not quite on point).

In general, nightlies are allowed to be somewhat unstable

Slightly less stable, in that they can make major version bumps between nightly versions, so are more bleeding edge. However, a project building a month ago on a nightly absolutely should not stop building a month later.

Again, really glad to see this resolved.

I agree that this is evidence for the utility of package revisions. However, it is also potentially evidence that this metadata should not be versioned along with the package itself. IMHO version constraints should always be external to package descriptions, as it inherently needs to be mutable, because you do not have total knowledge at time of publication. I've got further thoughts on this, which I hope to put into a blog post at some point (don't hold your breath though, heh!)

[tfausak]

Hey y'all. I would re-open this, but apparently I can't. These new caret bounds are a still a problem, but now it's because of base-4.10.1.0 instead of integer-gmp. I mentioned that a few days ago (#120 (comment)) but nobody has commented on it. This is causing real problems for me: https://ci.appveyor.com/project/TaylorFausak/rattletrap/build/294

Should I open a new issue for the ^>= bounds in base-4.10.1.0?

[gbaz]

I believe there are two solutions to the base issue, as discussed above. Either A) use the newest stack, or B) use a nightly snapshot prior to 8.2.2. As discussed above, it seems to me that this suffices.

[tfausak]

Indeed, upgrading Stack is a solution to this problem. So is downgrading to an older resolver. However those are also solutions to the original integer-gmp problem. I am interested in keeping existing build plans working. It used to be that using nightly-2017-11-25 with Stack 1.5.1 worked. As of December 4, it stopped working. If it's worth fixing integer-gmp, it seems like it should be worth fixing base too.