
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 distros.
(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. Duncan