[Haskell-cafe] Hackage policy question

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Tue Sep 9 18:59:17 EDT 2008

On Mon, 2008-09-08 at 16:26 -0700, Iavor Diatchki wrote:
> Hi,
> I just noticed that hackage has introduced a new policy to disallow
> changes to a package without bumping the version.  I understand that
> this is probably a good idea for changes to the source code, but it
> really would be nice to have a backdoor that allows for other changes.
>  For example, I just uploaded a package, and realized that I forgot to
> add a home-page entry in the cabal file.  I do not plan to increase
> the version number of my application, only so that I can upload a new
> version (the source code has not changed after all!).  I can imagine
> similar problems related to fixing typos in the description, and other
> fixes to the meta-data.

Yes. We've thought about this a bit. I'll tell you how I think it should
be managed, though I accept not everyone agrees with me.

The .tar.gz packages are pristine and must not change, however
the .cabal file that is kept in the hackage index could change and that
information will be reflected both in the hackage website and just as
importantly for tools like cabal-install. So not only could the
maintainer fix urls or whatever but also adjust dependencies in the
light of test results. Consider the analogy to pristine tarballs and
debian or gentoo meta-data files. The former never changes for a
particular version, but the meta-data can be adjusted as the
distributors see fit.

The difference here is that those two would be in the same format,
the .cabal file inside the tarball that never changes and the one in the
index which may do. This is also the objection that some people have,
that it would be confusing to have the two versions, especially that
unpacking the tarball gives the old unmodified version.

> So, could we please revert to the old policy?

No :-) But I hope with the above system that will not be necessary. I
hope to implement this feature in the new hackage server implementation
that I'll be announcing shortly.

Really it's essential that the md5sums of tarballs never change. Untold
chaos results if they are allowed to change. For one thing our urls
become unusable for distro systems like gentoo, fedora etc and they
would have to take snapshots and keep their own pristine mirrors rather
than using our url as the canonical reference (obviously they do their
own mirroring too but they usually refer back to a canonical source).
That would be a huge pain for them and a barrier to our acceptance into

> (if we really want to be fancy, the hackage upload script could check
> that the source code, and other fields, such as LICENSE have not
> changed, as these should really bump the version... in the mean time
> though, I think just being responsible members of the community would
> work just as well!).

Indeed we'll also have to check things carefully if we allow package or
distribution maintainers to adjust the .cabal files in the index. For
example changing exposed modules or the name or version number is right
out. We'll err on the restrictive side and gradually loosen as we decide
it's safe and acceptable.


More information about the Haskell-Cafe mailing list