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

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

[Robert Vollmert]

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

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

[Timothy Sample]

Hi Robert,

Robert Vollmert <rob@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

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

[Robert Vollmert]

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

Cheers
Robert

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

[Timothy Sample]

Hi,

Robert Vollmert <rob@vllmrt.net> writes:

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

bug#36084: not really fixed?

[Robert Vollmert]

It seems the two clock packages are still subtly different, apparently
due to the tested variant pulling in a dependency on the test libraries.

Compare https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36705.

Configuring tasty-hspec-1.1.5.1...
Warning:
    This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
      package hspec-core (hspec-core-2.5.5-H06vLnMfEeIEsZFdji6h0O) requires clock-0.7.2-9qwmBbNbGzEOSffjlyarp
      package tasty (tasty-1.1.0.3-I8Vu9v0lHj8Jlg3jpKXavp) requires clock-0.7.2-Cf9UTsaN2AjEpBnoMpmgkU

It’s possible that this warning is really just a warning, and that there’s
no real problem here because the packages are really the same, but… I
don’t like it.