[Haskell-cafe] Hackage policy question

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Thu Nov 20 05:52:38 EST 2008

On Wed, 2008-11-19 at 20:25 -0800, John Meacham wrote:
> The usual solution to this is the 'release version', which is used in
> most (all?) other packaging systems. namely, you have foo-1.2-4, where 4 is the
> release version which documents what version the meta-info is. For
> instance, when bugs are fixed in the rpm spec file or deb package that
> number is bumped and it is independent of the underlying packaged
> softwares release. It would be very useful if hackage could support
> something like this.

There are two solutions to this, one is to say it's just a convention,
eg using 1.2.4 when you give it your meaning of 1.2_4. The reason deb,
rpm etc need to distinguish the extra version is precisely because they
do not control the upstream version number. Of course in the case of
package authors uploading packages to hackage that is not the case. It's
an upstream packaging format, not a downstream one.

However when we want to manage a collection of packages on hackage then
it is a bit more like a downstream distro and in that case there is a
stronger argument for making tweaks to meta-data (without uploading new
tarballs) and recording those revision numbers. Eg relaxing or
tightening versions of constraints as new information becomes available.

One possibility there is to keep a version of the .cabal file outside of
the tarball in the hackage index and record a x-hackage-revision: 3
field in that. It'd be incremented each time someone (author/maintainer
or packager collection herder) makes a tweak.


More information about the Haskell-Cafe mailing list