Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • H head.hackage
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 13
    • Issues 13
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 8
    • Merge requests 8
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • head.hackage
  • Issues
  • #53
Closed
Open
Created May 16, 2022 by Ben Gamari@bgamari🐢Maintainer

A plan for enabling `index-state`

For a long time usability of head.hackage has suffered from the inability to freeze the state of the overlay in a particular project. A while back I met with with Andrea Bedini to discuss his work on foliage, a very nice tool for building Hackage repositories from a nice declarative input. This would serve as a very nice basis for head.hackage and happily, supporting both incremental builds and, crucially, index-state. We should move head.hackage's CI infrastructure towards foliage.

However, this will require that we slightly rethink how package versioning is handled. Currently patched packages retain their upstream package versions for simplicity. However, this will need to change in order to benefit from index-state since source tarballs are considered to be immutable in the Hackage index. At the same time, we will should avoid shadowing upstream package versions to avoid confusion. For this reason, I suggest that we version patched packages by bumping the fifth (sub-patch-level) component or, if the upstream version already has more than four components, the $n+1$th component. Concretely:

bumpVersionBy
    :: Int     -- ^ patch revision
    -> Version -- ^ upstream package version
    -> Version -- ^ patched package version
bumpVersionBy n ver =
    makeVersion ver'
  where
    n_comps = length (versionBranch ver)
    bump_comp = max 5 (n_comps + 1)
    bump = replicate (bump_comp-1) 0 ++ [n]
    ver' = zipWith (+) (versionBranch ver ++ repeat 0) bump

So we end up with,

bumpVersionBy 4 (makeVersion [1,0])         ===    Version {versionBranch = [1,0,0,0,4], versionTags = []}
bumpVersionBy 4 (makeVersion [1,0,0])       ===    Version {versionBranch = [1,0,0,0,4], versionTags = []}
bumpVersionBy 4 (makeVersion [1,0,0,0])     ===    Version {versionBranch = [1,0,0,0,4], versionTags = []}
bumpVersionBy 4 (makeVersion [1,0,0,0,0])   ===    Version {versionBranch = [1,0,0,0,0,4], versionTags = []}

Patch versions can be deduced from the commit history of the head.hackage repository. Specifically, I propose the following plan:

  • For each patch $patch in patches/:
    • For each git revision $commit of the patch (i.e. for each commit shown by git log $patch):
      • Extract the source tarball
      • Apply the patch from $commit
      • Modify the cabal's version number; see "versioning" below
      • Run cabal sdist
      • Place the resulting source distribution in the foliage tree
Assignee
Assign to
Time tracking