unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
* bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken
@ 2019-06-04  0:26 Robert Vollmert
  2019-07-16 15:08 ` Timothy Sample
  2019-07-17 14:13 ` bug#36084: not really fixed? Robert Vollmert
  0 siblings, 2 replies; 5+ messages in thread
From: Robert Vollmert @ 2019-06-04  0:26 UTC (permalink / raw)
  To: 36084

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken
  2019-06-04  0:26 bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken Robert Vollmert
@ 2019-07-16 15:08 ` Timothy Sample
  2019-07-16 16:17   ` Robert Vollmert
  2019-07-17 14:13 ` bug#36084: not really fixed? Robert Vollmert
  1 sibling, 1 reply; 5+ messages in thread
From: Timothy Sample @ 2019-07-16 15:08 UTC (permalink / raw)
  To: Robert Vollmert; +Cc: 36084

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken
  2019-07-16 15:08 ` Timothy Sample
@ 2019-07-16 16:17   ` Robert Vollmert
  2019-07-16 19:11     ` Timothy Sample
  0 siblings, 1 reply; 5+ messages in thread
From: Robert Vollmert @ 2019-07-16 16:17 UTC (permalink / raw)
  To: Timothy Sample; +Cc: 36084



> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken
  2019-07-16 16:17   ` Robert Vollmert
@ 2019-07-16 19:11     ` Timothy Sample
  0 siblings, 0 replies; 5+ messages in thread
From: Timothy Sample @ 2019-07-16 19:11 UTC (permalink / raw)
  To: Robert Vollmert; +Cc: 36084-done

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#36084: not really fixed?
  2019-06-04  0:26 bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken Robert Vollmert
  2019-07-16 15:08 ` Timothy Sample
@ 2019-07-17 14:13 ` Robert Vollmert
  1 sibling, 0 replies; 5+ messages in thread
From: Robert Vollmert @ 2019-07-17 14:13 UTC (permalink / raw)
  To: 36084

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-07-17 14:15 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-04  0:26 bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken Robert Vollmert
2019-07-16 15:08 ` Timothy Sample
2019-07-16 16:17   ` Robert Vollmert
2019-07-16 19:11     ` Timothy Sample
2019-07-17 14:13 ` bug#36084: not really fixed? Robert Vollmert

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).