GNU bug report logs - #36084
ghc-tasty/ghc-clock circular dependency breaking is broken

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Robert Vollmert <rob <at> vllmrt.net>
Subject: bug#36084: closed (Re: bug#36084: ghc-tasty/ghc-clock circular
 dependency breaking is broken)
Date: Tue, 16 Jul 2019 19:12:01 +0000

[Message part 1 (text/plain, inline)]

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 36084 <at> debbugs.gnu.org.

-- 
36084: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36084
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Timothy Sample <samplet <at> ngyro.com>
To: Robert Vollmert <rob <at> vllmrt.net>
Cc: 36084-done <at> debbugs.gnu.org
Subject: Re: bug#36084: ghc-tasty/ghc-clock circular dependency breaking is
 broken
Date: Tue, 16 Jul 2019 15:11:00 -0400

Hi,

Robert Vollmert <rob <at> vllmrt.net> writes:

>> On 16. Jul 2019, at 17:08, Timothy Sample <samplet <at> ngyro.com> 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

[Message part 3 (message/rfc822, inline)]

From: Robert Vollmert <rob <at> vllmrt.net>
To: bug-guix <at> gnu.org
Subject: ghc-tasty/ghc-clock circular dependency breaking is broken
Date: Tue, 4 Jun 2019 02:26:04 +0200

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?)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.