[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Standardizing the layout of git packaging repositories



Hello,

while git is the most popular VCS for packaging, there's no clear rules
on what you can expect in a random git packaging repository listed
in Vcs-Git. I would like to fix this so that:
- we can extract more useful data from the git repositories
- we can more easily share our git repositories with upstreams
  and downstreams
- we start to converge on some conventions even though we might
  continue to use different git helper tools

I want to use the DEP process for this. But before I can write a first
draft I would like to have your ideas of what we should include
in such a document.

Some initial questions and possible answers:

- how do we name the various branches?

  - <vendor>/master for the main development trunk (aka unstable in Debian)
  - <vendor>/<codename> for alternate versions

  The goal here is to be able to host in the same repository the branches for
  multiple cooperating distributions (at least so that downstream can
  clone the debian respository and inject their branches next to the
  debian branches).

- how do we tag the upstream releases?

  - upstream/<version>
  (note: we don't need an "upstream" branch, having the good tag for any
  release that the distros are packaging is enough, it can point to a
  synthetic commit built with tools like git-import-orig or to a real
  upstream commit)

- how do we tag the package releases?

  - pkg/<version>
  (note: git-buildpackage uses debian/<version> but I find this confusing
  as we then also have the "debian/" prefix for ubuntu or kali uploads, we
  don't need the vendor prefix as the usual versioning rules embed the
  downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
  any conflict on the namespace, keeping a prefix is important to easily
  differentiate tags created by upstream developers from tags created
  by packagers)

- where should the HEAD point to in the public repository?

- shall we standardize the "pristine-tar" branch?

- the above layout is for the traditional case of non-native packages,
  what would be the layout for native packages? how can be differentiate
  between native/non-native layout?
  
- <version> encoding (due to git restrictions):
    ":" -> "%"
    "~" -> "_"

- are there other important things to standardize?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


Reply to: