Cabal mismatch in ghc-lucid; long-term archiving Haskell?

[zimoun]

Hi,

Let try to build the Haskell package ghc-lucid.

--8<---------------cut here---------------start------------->8---
$ guix build ghc-lucid
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
  /gnu/store/9m71fs1i0anv89f5zq44hbh2wn2lavxz-ghc-lucid-2.9.12.1.drv
  /gnu/store/i62zr0ykqyxfwyc270csnhbwyrk3l3bb-ghc-lucid-2.9.12.1-1.cabal.drv
building 
/gnu/store/i62zr0ykqyxfwyc270csnhbwyrk3l3bb-ghc-lucid-2.9.12.1-1.cabal.drv...

Starting download of 
/gnu/store/rj33x41i86vgw6c0iwffzwrgzrib1shb-ghc-lucid-2.9.12.1-1.cabal
>From https://hackage.haskell.org/package/lucid-2.9.12.1/revision/1.cabal...
downloading from 
https://hackage.haskell.org/package/lucid-2.9.12.1/revision/1.cabal ...
 1.cabal                                                                        
    345KiB/s 00:00 | 3KiB transferred
sha256 hash mismatch for 
/gnu/store/rj33x41i86vgw6c0iwffzwrgzrib1shb-ghc-lucid-2.9.12.1-1.cabal:
  expected hash: 1f0whk5ncanxfjjanrf6rqyncig2xgc5mh2j0sqy3nrlyjr9aqq9
  actual hash:   1xllyf26ypk37k807g5v6fl1449mhpvk18dljmqgwj723n0v8rpj
hash mismatch for store item 
'/gnu/store/rj33x41i86vgw6c0iwffzwrgzrib1shb-ghc-lucid-2.9.12.1-1.cabal'
build of 
/gnu/store/i62zr0ykqyxfwyc270csnhbwyrk3l3bb-ghc-lucid-2.9.12.1-1.cabal.drv 
failed
View build log at 
'/var/log/guix/drvs/i6/2zr0ykqyxfwyc270csnhbwyrk3l3bb-ghc-lucid-2.9.12.1-1.cabal.drv.gz'.
cannot build derivation 
`/gnu/store/9m71fs1i0anv89f5zq44hbh2wn2lavxz-ghc-lucid-2.9.12.1.drv': 1 
dependencies couldn't be built
guix build: error: build of 
`/gnu/store/9m71fs1i0anv89f5zq44hbh2wn2lavxz-ghc-lucid-2.9.12.1.drv' failed
--8<---------------cut here---------------end--------------->8---

and indeed, ci.guix.gnu.org is also failing (since May) with the same
message.  See <https://ci.guix.gnu.org/build/750925/details>.

The reason is because,

--8<---------------cut here---------------start------------->8---
    (arguments
     `(#:cabal-revision
       ("1"
        "1f0whk5ncanxfjjanrf6rqyncig2xgc5mh2j0sqy3nrlyjr9aqq9")))
--8<---------------cut here---------------end--------------->8---

Hopefully, we have an old substitute for this Cabal file on
bordeaux.guix.gnu.org.

Therefore, we can compare both:

--8<---------------cut here---------------start------------->8---
$ diff error.cabal pass.cabal
2,3c2,3
< version:             2.9.12.1
< x-revision: 1
---
> version:             2.9.12
> x-revision:          1
23c23
< cabal-version:       >=1.10
---
> cabal-version:       >=1.8
25c25
< tested-with:         
GHC==7.10.3,GHC==8.0.2,GHC==8.2.2,GHC==8.4.4,GHC==8.6.5,GHC==8.8.4,GHC==8.10.4,GHC==9.0.1
---
> tested-with:         
> GHC==7.10.3,GHC==8.0.2,GHC==8.2.2,GHC==8.4.4,GHC==8.6.5,GHC==8.8.3,GHC==8.10.1
28d27
<   default-language:  Haskell2010
37c36
<   build-depends:     base                   >=4.8      && <4.16
---
>   build-depends:     base                   >=4.8      && <4.15
43c42
<   build-depends:     mtl                    >=2.2 && < 2.3
---
>   build-depends:     mtl                    >=2.2
56,59d54
< source-repository head
<   type:     git
<   location: https://github.com/chrisdone/lucid.git
< 
61d55
<     default-language: Haskell2010
76d69
<   default-language: Haskell2010
91d83
<   default-language: Haskell2010
--8<---------------cut here---------------end--------------->8---


And it is where I am confused. :-)  The Hackage entry of the Haskell
package Lucid says:

     https://hackage.haskell.org/package/lucid-2.9.12.1/revisions/

which corresponds to only one line in the diff.  All the other means
that the time-machine could break.


Is it a manual in-place replacement?  Or is it an automatic in-place
update by Hackage infrastructure?  Or do I miss a point?

In all cases, these revised Cabal files are not archived elsewhere than
in Hackage, right?  The question is thus, where could we archive them?

Note that the both items have the same store-address hash
(/gnu/store/rj33x41i86vgw6c0iwffzwrgzrib1shb-ghc-lucid-2.9.12.1-1.cabal)
but not the same content hash.


Any idea?


Cheers,
simon