Hi, On Tue, 08 Mar 2022 at 11:04, zimoun <zimon.touto...@gmail.com> wrote: > On dim., 28 nov. 2021 at 02:50, John Kehayias <john.kehay...@protonmail.com> > wrote: > >> While working on importing a bunch of Haskell packages, I came across >> a cycle created by the importer (twice actually, but forgot the other >> one). Perhaps this is from the metadata from Hackage, as it doesn't >> create the cycle when importing from Stackage. Here are the outputs: > > The difference comes from upstream: > > - hackage fetches from > https://hackage.haskell.org/package/OneTuple/OneTuple-0.3.1.tar.gz > - stackage fetches from > https://hackage.haskell.org/package/OneTuple/OneTuple-0.2.2.1.tar.gz > > Therefore, it is not the same version. Let compare:
[...] > And the "cycle" seems expected from OneTuple.cabal: > > $ cat OneTuple-0.3.1/OneTuple.cabal > cabal-version: >=1.10 > > [...] > > test-suite th > type: exitcode-stdio-1.0 > default-language: Haskell98 > hs-source-dirs: test > main-is: th.hs > build-depends: > base > , OneTuple > , template-haskell > > > Well, for what they are worth, based on this remark, two points: > > 1. I do not know what could be done on Guix side. An idea? > 2. Usually, it is recommended to follow LTS and so Stackage. I do not think it is a bug from Guix but a bug from OneTuple upstream, not in their version 0.2.2.1, and introduce by their version 0.3.1. We could introduce a detection for cycles. But nothing is broken or raise a Backtrace. Somehow, the importers are some helper and not bullet-proof one-to-one mapping, IMHO. I propose to close this bug if no more idea. WDYT? Cheers, simon
