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
