Re: Hackage revisions and the current breakage of https://jenkins.debian.net/view/haskell/job/haskell-package-plan/

[Ilias Tsitsimpis <iliastsi@debian.org>]

Hi Mikolaj,

On Thu, Jun 21, 2018 at 09:43PM, Mikolaj Konarski wrote:
> 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.

You are right. This happens from time to time, when metadata for a
package get updated on Hackage. In my opinion, it is unfortunate that
Hackage allows for metadata to be updated without changing the version
of a package, because this means that releases are not immutable.

Luckily, the original tarball stays the same, and since this is what
we use when packaging for Debian, we always end up using the first
revision.

Now, as you already said, package-plan is another story. It uses cabal
for testing co-installability of our packages, and hence always
retrieves the latest available revision which is *not* what we want,
since it differs from what the actual Debian packages use.

> Which way do we want to go?

We should probably, at some point, modify package-plan to always use the
first revision for the packages it tests. Until then, there are two
options:

a) Modify the patch to apply to the latest revision. This is a short
term solution, since it will fail as soon as the maintainer uploads a
new revision.

b) Instruct package-plan to use the rev0 for this particular package, by
placing the cabal file in the additional-cabals folder. From README.md:

 * `additional-cabals/<pkg>-<version>.cabal`
   Adds the given files to the internal “repository”, possibly overwriting
   exiting packages.
   This can be used for packages not on hackage, or when the cabal-file editing
   feature on hackage has been used. In that case, the unmodified cabal file
   ought to be added here.

I prefer the second one, since it matches the package published by Debian.

-- 
Ilias