unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Federico Beffa <beffa@ieee.org>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: propagating inputs in ghc-* packages
Date: Sat, 01 Oct 2016 09:45:21 +0200	[thread overview]
Message-ID: <871t00v7fy.fsf@elephly.net> (raw)
In-Reply-To: <CAKrPhPNrzBpYFMrtF6jBsLUtVYa0rPmHxx5p1k5EHknjxiW+KQ@mail.gmail.com>


Federico Beffa <beffa@ieee.org> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Hi Guix,
>>
>> I’m in the middle of upgrading our Haskell packages.  (Actually, I’m
>> just yak shaving.  I need “pandoc-citeproc” for “r-knitr”…)
>>
>> I noticed that upgrading Haskell packages is a pain in the neck because
>> of propagated inputs.  It seems that not all packages have fully
>> declared dependencies and just work accidentally because of propagated
>> inputs of a related package.  This also makes upgrades more difficult
>> because I can get substitutes from Hydra that depend on older versions
>> of some Haskell packages.
>>
>> It looks like Haskell binaries actually embed references to other
>> Haskell packages, so I’m not sure we actually need to propagate anything
>> at all.  Could someone please confirm this?
>
> From what I recall, binary executables include references to packages,
> but libraries do not.  So, at least at the time I wrote the first
> version of the haskell-build-system, propagated inputs seemed to be
> necessary for packages providing libraries, but not for ones providing
> applications.

Thanks for this comment.  With Eric Bavier’s patch this seems no longer
necessary.  I’ve already rebuilt a lot of Haskell packages without any
propagation (and some added inputs), and I’ve got working libraries and
executables.  I’m still rebuilding remaining Haskell packages but I’m
now convinced that propagation is no longer needed with the current
version of the build system.

I’m preparing a patch to remove propagation from all Haskell packages.
Now the question is only whether to do this all in one patch or in one
patch per package… :)

~~ Ricardo

  reply	other threads:[~2016-10-01  7:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-30 21:07 propagating inputs in ghc-* packages Federico Beffa
2016-10-01  7:45 ` Ricardo Wurmus [this message]
2016-10-01  9:14   ` Federico Beffa
2016-10-02  4:21     ` Ricardo Wurmus
2016-10-02 15:42       ` Federico Beffa
2016-10-01 16:31   ` Leo Famulari
  -- strict thread matches above, loose matches on Subject: below --
2016-09-30  9:24 Ricardo Wurmus
2016-09-30 14:37 ` Eric Bavier
2016-10-02 11:59   ` Ricardo Wurmus

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=871t00v7fy.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=beffa@ieee.org \
    --cc=guix-devel@gnu.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).