all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Federico Beffa <beffa@ieee.org>
To: Troy Sankey <sankeytms@gmail.com>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: updating many haskell packages
Date: Fri, 17 Feb 2017 09:00:04 +0100	[thread overview]
Message-ID: <CAKrPhPN7nwuAV4nN+EUrdi_ZFuU7rr0t=dMVUdLEgusEgBWcmA@mail.gmail.com> (raw)
In-Reply-To: <148718709098.32672.6688568200387118544@what>

On Wed, Feb 15, 2017 at 8:31 PM, Troy Sankey <sankeytms@gmail.com> 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	other threads:[~2017-02-17  8:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-06  8:03 updating many haskell packages Federico Beffa
2017-02-06  8:13 ` Federico Beffa
2017-02-15 19:07   ` Troy Sankey
2017-02-17 16:43     ` Ricardo Wurmus
2017-02-06 15:23 ` Troy Sankey
2017-02-06 20:34   ` Federico Beffa
2017-02-06 21:00     ` Troy Sankey
2017-02-15 19:31       ` Troy Sankey
2017-02-17  8:00         ` Federico Beffa [this message]
2017-02-17 17:47           ` Troy Sankey
2017-02-18  9:43             ` Federico Beffa
2017-02-18 17:40               ` Troy Sankey
2017-02-18 20:23                 ` Federico Beffa
2017-02-19 19:21                 ` Troy Sankey
  -- strict thread matches above, loose matches on Subject: below --
2017-02-06  5:23 Troy Sankey
2017-02-06 15:47 ` Leo Famulari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKrPhPN7nwuAV4nN+EUrdi_ZFuU7rr0t=dMVUdLEgusEgBWcmA@mail.gmail.com' \
    --to=beffa@ieee.org \
    --cc=guix-devel@gnu.org \
    --cc=sankeytms@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.