Hackage revisions and the current breakage of https://jenkins.debian.net/view/haskell/job/haskell-package-plan/
Hi!
Currently https://jenkins.debian.net/view/haskell/job/haskell-package-plan/
is broken, because our patch for haskell-hackage-security applies fine
for the declared version, but doesn't apply for the revision-1 of the package
that is hosted on Hackage and that changes line endings to CRLF
for some silly technical reason. We take the .cabal files to be patched
using 'cabal update', which just take the lastest revision, while we actually
mean the initial revision and in this case it bites us.
I talked with Herbert about it and he enlightened me in the following
actionable words:
21:15 <hvr> I think you can easily summarise this
21:16 <hvr> a) the CRLF thing is a side-effect of the browser
interaction; if you use hackage-cli this doesn't happen
21:16 <hvr> b) but ultimately, a) shouldn't matter, if the proper
packaging model is used
21:17 <mikolaj> yep
21:18 <hvr> which means, either ignore metadata revisions, and always
start from the original .tar.gz (i.e. rev0) if you require patches
against a .cabal file to be indexed by the package version number
21:19 <hvr> *or* include hackage metadata revisions properly into the
packaging model, by considering a sub-versioning, not unlike debian's
own revision part of the version number
21:21 <mikolaj> right
21:43 * mikolaj bows
Which way do we want to go?
Reply to: