guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: updating many haskell packages


From: Federico Beffa
Subject: Re: updating many haskell packages
Date: Fri, 17 Feb 2017 09:00:04 +0100

On Wed, Feb 15, 2017 at 8:31 PM, Troy Sankey <address@hidden> wrote:
> 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?

Packages are build in isolated environments without network.
Therefore it's not possible to access Hackage with a phase of the
build system.  Even if it were possible it would be undesirable
because it would make things non reproducible.

Files not included in the tar can be added as origin inputs to a
package definition (see the testsuite for GHC in the ghc package).
However, they are verified with hashes. Any change to those files will
break the package.

Fede



reply via email to

[Prev in Thread] Current Thread [Next in Thread]