
I repeatedly encounter the following versioning problem on Hackage: There is a package A with version 1.0. I upload a package B which imports A. Thus B is bound to A-1.0 Now a new version of A is uploaded, say 1.0.1. then I upload package C which depends both on A and B. However C is bound to the new A-1.0.1, which gives conflicts with the interface of B. All packages are sane. Both B and C work with either A-1.0 or A-1.0.1, but they must use the same version. Currently I'm forced to upload many packages with different versions, although nothing really changed. Maybe the most easiest fix to this problem is to let maintainers of a package allow to trigger re-configuration and re-compilation of a package. I would also like to flag package versions that people can safely ignore, because there was a flaw in package dependencies. On the other hand there are packages that are useful, but can no longer be compiled on Hackage, e.g. compatibility packages for older versions of GHC.

On Mon, 2009-01-12 at 13:21 +0100, Henning Thielemann wrote:
I repeatedly encounter the following versioning problem on Hackage: There is a package A with version 1.0. I upload a package B which imports A. Thus B is bound to A-1.0 Now a new version of A is uploaded, say 1.0.1. then I upload package C which depends both on A and B. However C is bound to the new A-1.0.1, which gives conflicts with the interface of B. All packages are sane. Both B and C work with either A-1.0 or A-1.0.1, but they must use the same version.
The package builder on hackage is broken for this reason, amongst others.
Currently I'm forced to upload many packages with different versions, although nothing really changed. Maybe the most easiest fix to this problem is to let maintainers of a package allow to trigger re-configuration and re-compilation of a package.
The plan with the new hackage server is that we have a smarter build client (cabal-install) that does install plans and so always installs consistent versions of packages.
I would also like to flag package versions that people can safely ignore, because there was a flaw in package dependencies.
There is a mechanism for doing this but no UI yet.
On the other hand there are packages that are useful, but can no longer be compiled on Hackage, e.g. compatibility packages for older versions of GHC.
Right, we should leave those alone. Duncan
participants (2)
-
Duncan Coutts
-
Henning Thielemann