GNU bug report logs -
#36084
ghc-tasty/ghc-clock circular dependency breaking is broken
Previous Next
Reported by: Robert Vollmert <rob <at> vllmrt.net>
Date: Tue, 4 Jun 2019 00:27:01 UTC
Severity: normal
Done: Timothy Sample <samplet <at> ngyro.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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?)
This bug report was last modified 5 years and 311 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.