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: Timothy Sample <samplet <at> ngyro.com>
To: Robert Vollmert <rob <at> vllmrt.net>
Cc: 36084 <at> debbugs.gnu.org
Subject: bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken
Date: Tue, 16 Jul 2019 11:08:04 -0400

Hi Robert,

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

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

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

Sorry for taking so long to get to this, BTW.  :(


-- Tim

Previous Next

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