Inaccurate/missing version bounds

[hvr]

Describe the bug

Inaccurate/omitted version bounds in package description

As can be seen at https://matrix.hackage.haskell.org/package/miso@1548087346 this has a devastating effect on Hackage users as it effectively means that the miso package descriptions are underspecified and Cabal therefore doesn't have enough information to compute sound (i.e. that typecheck and are semantically sound) build-plans. In other words, all red cells om that report are symptoms of the bug at hand.

In order to fix this it'll be necessary to reconstruct/reverse-engineer the appropriate bounds and retroactively inject them into all affected miso releases via Hackage metadata revision as this can not be resolved by (only) uploading a new release of miso as cabal's constraint solver will still be allowed to backtrack to any of the previous releases with missing/inaccurate bounds. You can do this yourself via

• https://hackage.haskell.org/package/miso-0.21.2.0/miso.cabal/edit
• https://hackage.haskell.org/package/miso-0.21.1.0/miso.cabal/edit
• ...through...
• https://hackage.haskell.org/package/miso-0.1.0.0/miso.cabal/edit

https://hackage.haskell.org/package/floskell-0.9.0/floskell.cabal/edit

or, in my function as Hackage Trustee, I can assist you and help you with the revisions.

Going forward, we need your help! Please help us ensure a good user experience for users of Hackage/Cabal by the use of the PVP mandated lower&upper bounds in order to reduce the penalty on the Hackage infrastructure as well as to avoid unnecessary extra work for you as well as for us Hackage Trustees!

The use of CI testing (such as https://github.com/haskell-CI/haskell-ci) can greatly help identify & prevent such incidents early on before they enter the primary Hackage index. Let me know if you need any assistance with CI or have any questions related to it.

[dmjio]

@hvr thanks for posting this. Admittedly, miso could be doing a better job at supporting the hackage / cabal workflow. The main reason for not supporting this first class is in large part due to the difficulty in obtaining / using ghcjs for newcomers, as opposed to using the stack / nix pinned version approach.

With that being said I am all for retroactively adding version bounds to help the cabal workflow if indeed this is showing errors for users, and also simply for the fact that miso should be a model cabal package. Would I need to know historical bounds information on packages to accomplish this task?

[hvr]

difficulty in obtaining / using ghcjs for newcomers

btw, I hope that'll get better soon. I've started packaging ghcjs for Ubuntu some time ago, see https://launchpad.net/~hvr/+archive/ubuntu/ghcjs and I plan to polish this a bit more and also support Debian. By covering Ubuntu+Debian this should cover a huge target-audience on Linux. Going forward, we may also add support to ghcup for GHCJS installs, and extend support to macOS that way. Windows can be supported via the Chocolatey manager if I can provide Tamar with a working build-recipe that works on Windows... :-)

Would I need to know historical bounds information on packages to accomplish this task?

In principle we have all historical information of the Hackage index contained in the 01-index.tar, but if we use that information to infer historic upper bounds we risk being overly restrictive and break valid build-plans that were already in use. I'll investigate a bit more what can be done easily and get back to you on this.

[dmjio]

#793

[dmjio]

@hvr @georgefst strategy here is to release 1.9, update 1.8 and couple other major releases to have the same version bounds, then deprecate the rest. Sound good?