Re: updating many haskell packages

[Troy Sankey]

Quoting Troy Sankey (2017-02-06 16:00:29)
> Quoting Federico Beffa (2017-02-06 15:34:47)
> > I would consider a discrepancy between a cabal file on Hackage and the
> > actual cabal file included in a tar archive a bug.  It may be helpful
> > to report it to the author.
> 
> I found this issue on the hackage github:
> 
> https://github.com/haskell/hackage-server/issues/503
> 
> It looks like it's a feature of hackage and/or cabal to allow multiple
> revisions of cabal files per tarball release.  IIUC, the `cabal get`
> utility takes care of automatically updating the cabal file to the
> latest revision.
> 
> I'll have to look more into this later.

Indeed the .cabal files can be revised between releases.  Somehow the
new revisions get pushed to the all-cabal-files repository [0] with an
additional "x-revision" key [1], and Hackage picks up the new cabal
file.  The `cabal` and `stack` utilities substitute the .cabal file from
the release tarball with the revised .cabal file from Hackage if it is
newer.

In theory, anything in the .cabal file could be modified, not just
dependency bounds.  I think guix should use the updated .cabal files for
better consistency with the rest of the haskell ecosystem, and also for
less per-package maintenance cost.

How can guix adapt?  Should we somehow incorporate the all-cabal-files
repository in the haskell build system, adding a post-unpack phase to
substitute the entire .cabal file?

Troy

[0] https://github.com/commercialhaskell/all-cabal-files
[1] 
https://github.com/commercialhaskell/all-cabal-files/blob/hackage/old-time/1.1.0.3/old-time.cabal#L3

signature.asc
Description: signature