Subject: bug#36084: closed (Re: bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 16 Jul 2019 19:12:01 +0000

Your bug report

#36084: ghc-tasty/ghc-clock circular dependency breaking is broken

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
36084: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36084
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken
From: Timothy Sample <[email-masked]>
To: Robert Vollmert <[email-masked]>
Cc: [email-masked]
Date: Tue, 16 Jul 2019 15:11:00 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi,

Robert Vollmert <[email-masked]> writes:

>> On 16. Jul 2019, at 17:08, Timothy Sample <[email-masked]> wrote:
>> 
>> Hi Robert,
>> 
>> After looking at this and your patch at <https://bugs.gnu.org/36249>,
>> I’m wondering if it works as long as we make sure the versions match.
>> Can we just inherit the current “ghc-clock”, disable its tests, and call
>> it “ghc-clock-bootstrap”?  Is the Cabal consistency checking too clever
>> for that?
>> 
>> If that doesn’t work, can you explain why the method you proposed above
>> doesn‘t work?  It seems a little simpler than your patch.  In fact,
>> maybe we could live with the main “ghc-tasty” package being built
>> without “ghc-clock” (via the flag you mentioned).
>
> I tried the direct approach again, and this time it worked. Posted an
> updated patch.
>
> I believe this should be fine, since GHCs builds should be deterministic.

It looks like this is a common idiom for us, so I’m pretty confident,
too.  Fixed in 71e5d425c9b9e108ebdd06d13de45b56dddd9ef5.  Thanks!

-- Tim

Subject: ghc-tasty/ghc-clock circular dependency breaking is broken
From: Robert Vollmert <[email-masked]>
To: [email-masked]
Date: Tue, 4 Jun 2019 02:26:04 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

ghc-tasty depends via “inputs” on ghc-clock-bootstrap (v0.5) which is built without tests,
while ghc-clock (v0.7) depends via “native-inputs” on ghc-tasty for tests.

This means that any package which depends on ghc-tasty and ghc-clock is potentially broken,
e.g.:

Warning:
    This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
      package tasty (tasty-1.1.0.3-98rSghuW4l26JGzzQLN3ha) requires clock-0.5.1-KAiVgaxjUlIIuEB7RoOIe6
      package hspec-core (hspec-core-2.5.5-BSfG8Pnx1al9rTpu1j0PaW) requires clock-0.7.2-JStwYFlKVmNHl0K1ll1Mx5

I’d suggest breaking the cycle instead by

1. introducing tasty-bootstrap which builds against the `time` module via the cabal flags:

flag clock
  description:
    Depend on the clock package for more accurate time measurement
  default: True

This could be done via
  (arguments `(#:configure-flags (“—flag=-clock”)))
as far as I understand.

2. changing ghc-clock to test via tasty-bootstrap (and possibly some more variant testing
packages that would be changed to depend on tasty-bootstrap)

3. changing tasty to test via ghc-clock.

(I gave this approach a shot myself, but I’m running into mysterious silently hanging guild and guix build
processes — possibly some cyclic dependencies which are noticed?)