From ArchWiki
Jump to navigation Jump to search



  • one git repo per package
    • signed git tags for each (epoch:)pkgver-pkgrel (unique)
    • branches unimportant, free for developer to use
  • db-update checks to-be-published packages match tags in repos
    • git show "$tag:$path"; also works in bare clones (no working copy)
  • merge packages and community (rethink security setup)
    • still use dev & tu groups
  • maintain git repo of db contents for history
    • subdirs for each repo-arch (core-x86_64, etc.)
    • generate repo submodule
  • maintain git repo of submodules matching db contents for history
    • use this for ABS


  • Easily find released versions of packages (just git checkout the tag)
  • History of packages in repositories (can find out what was when where)
  • Use git! (no stupid git-svn)
    • Less rigid repository structure. Easily make multiple branches track development and release from.
  • Tags are signed with our GPG keys
  • historical ABS

2015-04-03 (Namespace experiment)

  • keep all packages in a single repository, separated by namespaces
  • only one repository to configure
  • improves storage efficiency
  • avoids local duplication of trees
    • branches combining all the individual packages can be maintained via git read-tree
      • this is even faster than git-subtree
  • worsens locality and increases repo contention
    • with packed objects and packed refs git is pretty good at dealing with lots of objects and refs, though, unlike lots of submodules
  • smart http clients can interact with the namespaced refs as if they were separate repositories, see git-http-backend(1) and gitnamespaces(7)
    • makes creating and deleting "repos" simpler: just push
      • a post-receive hook should take care of creating or deleting the namespace HEADs using git-symbolic-refs
        • if a master branch is created (old sha1 is 40 zeroes), point HEAD to it
        • if a master branch is deleted (new sha1 is 40 zeroes), delete the HEAD
    • does this work with the ssh protocol or the git daemon?
  • can clone the whole repo, though the contained namespaces won't be pulled by default. they can be, though!
  • how do namespaces interact with gitweb/cgit? do we even want to run that on the repo server?
    • the web server might need to maintain individual repos anyway
    • a post-receive hook could push updates to the web server
    • the web server could poll the main repo and separate the namespaces into clones locall
  • access control? I assume we want to disallow TUs from pushing to dev repos
    • record user's group (dev or tu) when creating a namespace?
    • although namespaces can be hierarchical, I'd rather have a flat namespace of packages than the packages/community distinction we have now