On Wed, 2008-09-10 at 10:11 +0200, Wolfgang Jeltsch wrote:
Am Mittwoch, 10. September 2008 00:59 schrieb Duncan Coutts:
[…]
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.
I don’t think this is a good idea. The package description, list of exposed modules, etc. belongs to the software, in my opinion. So changing it means changing the software which should be reflected by a version number increase.
Remember that all the distributors are doing this all the time and it doesn't cause (many) problems. They change the meta-data from what the upstream authors give and they add patches etc etc. Granted, they do use a revision number to track this normally. For example a package foo-1.0 on hackage would become dev-haskell/foo-1.0.ebuild in gentoo and if it needs to be updated for some reason it becomes dev-haskell/foo-1.0-r1.ebuild and the number is increased by one for every subsequent revision. Distros like debian have similar systems.
Why can’t package maintainers double-check that they got everything in the Cabal file right before the package is uploaded to Hackage? And if one has forgotten a URL or something like that, it is still possible to release a new version where just the 4th component of the version number was changed which means precisely that the interface didn’t change.
Note that the distros are actually making code changes (applying bug fix patches) and not bumping the upstream version number, though they do bump their additional revision number. I'm not suggesting anything so radical. I'm just suggesting that you could change the category tags, or improve the description. The most radical thing is tightening or relaxing the version constraints on dependencies. For example if your package depends on foo >= 1.0 && < 1.1 but then foo-1.1 comes out and although it does contain api changes and had the potential to break your package (which is why you put the conservative upper bound) it turns out that you were not using the bits of the api that changed and it does in fact work with 1.1 so you can adjust the dependencies to foo >= 1.0 && < 1.2. Again, this is just the sort of thing that distros do.
[…]
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.
Yes, it *is* confusing.
[…]
I hope to implement this feature in the new hackage server implementation that I'll be announcing shortly.
May I kindly ask you to *not* implement this feature?
Well we need something like it I think. At least if we want to be able to install things direct from hackage and have some level of reliance on stated dependencies reflecting reality. It also allows us to share some QA between all the distros which have to do this work anyway. If we consider hackage as a raw upstream package collection that gets picked over and QA'd by the distros then it's not necessary. But I think we want to use it for both, for pristine upstream tarball releases but also I think we expect to be able to use it directly with things like cabal-install and so adding some distro-like management features is useful. So we should think about how to make it less confusing. Perhaps like distributors use an extra revision number we should do the same. I had hoped that would not be necessary but that's probably not realistic. Duncan