[Haskell-cafe] Hackage policy question
duncan.coutts at worc.ox.ac.uk
Wed Sep 10 05:47:20 EDT 2008
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
> 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
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.
More information about the Haskell-Cafe