
Ketil Malde
Aleksey Khudyakov
writes: Adding more restrictive constraints does not work, the broken package will be on hackage forever, while adding a new version with relaxed constraints works well.
That illustrate real problem It's not possible to specify correct version constraints when package is uploaded. So one have to choose between optimistic and conservative approach. Both have disadvantages. In ideal world one need ability to adjust version bounds after package upload.
+1. Metadata (i.e. the cabal file) chould be editable. In addition to adjusting dependency bounds, Hackage (or third party build servers) could add Tested-With, and there could be a deprecated field added when problems are discovered.
The last version component (D in A.B.C.D) could be considered the metadata version. Then cabal could be changed to only take into account the highest D-values. Alternatively, if the semantics of D cannot be changed, make it A.B.C.D_M (M for metadata version). That's the way MacPorts handles the problem. Tobi