最近研究了下ubuntu下的打包方法，发现DEP-14还是很有帮助的，简单翻译一下。
原文链接：http://dep.debian.net/deps/dep14/
目前还是草稿阶段，可以时刻关注。

标题：Git打包仓库的推荐布局
DEP：14
状态：草稿
日期：2016-11-09
推动：Raphael Hertzog hertzog@debian.org
链接：http://dep.debian.net/deps/dep14/
源码：http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn
摘要：使用Git仓库进行Debian打包的推荐命名约定

介绍

这是一个协调用于维护Debian打包工作的Git仓库的建议，有以下目的：
使Debian及其衍生版本更容易在在各自的Git仓库上进行构建（在某些情况下有可能共享一个仓库）

在各种git打包工具之间方便的进行切换。即使所有的工具没有实现相同的工作流，但是至少他们可以有一个同样的命名约定（Debian/上游发布标签，默认打包分支，等）。

范围

本建议为各种在做Debian打包工作相关的Git分支和Git标签定义了命名约定。希望Git打包辅助工具的维护者可以适应这些命名约定（在各自工具的默认配置当中）。

一般原则

---

供应商命名空间

每一个“供应商”在其打包相关的Git分支和标签中使用其自己的命名空间，比如：Debian使用debina/，Ubuntu使用ubuntu/，等等。
辅助工具通常依赖于dpkg-vendor --query vendor的结果来确认当前的供应商。检索的结果通常需要转换成小写字母。这允许用户通过设置环境变量DEB_VENDOR来覆盖当前供应商（供应商的信息存在于/etc/dpkg/origins/中）。
如果dpkg-vendor不起作用，辅助工具通常以“debian”作为默认值。通常这些工具也会提供相应的命令行参数以设置供应商。

版本调整

当一个Git标签需要参照一个指定的Debian包版本的时候，版本需要调整并适应Git的限制。这种调整是确定并可逆的：

• 每一个冒号（:）需要替换成百分号（%）
• 每一个波浪字符（_{）需要替换成（}）需要替换成下划线（_）
• 每一对相邻的点号（..）中逐渐需要插入一个井号（#）
• 如果最后一个字符为点号（.）需要在其后加上一个井号（#）
• 如果版本以.lock结尾，需要在点号（.）后面插入一个井号（#）变成.#
  lock

这可以用以下的Perl5语句简明的表达：

y/:~/%_/;
s/\.(?=\.|$|lock$)/.#/g;

反向转换：

• 每一个百分号（%）替换成一个冒号（:）
• 每一个下划线（_）替换成一个波浪字符（~）
• 删除井号（#）

打包相关分支和标签

---

通常来说，打包的分支需要根据目标发行版的代号进行命名。然而我们将开发版本与其他版本进行区分。

开发版本

上传到当前开发分支的软件包应该在<vendor>/master分支中准备。
然而，当多个开发版本经常使用的时候（比如Debian中的unstable和experimental），也可以接受根据目标分发的代号或套件名称命名分支（也可以是debian/sid或者debian/unstable，以及debian/experimental）。这些分支可以是短生命周期的（例如，这些分支可能这些分支可能只保留到被合并到<vendor>/master或者相关的仓库中被<vendor>/master分支中的版本），也可以是永久的（如果<vendor>/master不存在的话）。

注意：如果debian/control中Vcs-Git字段列出的Git仓库没有指明分支（以-b <branch>作为后缀），那么它会把HEAD指向用来打包的最新的上游版本的分支（一个关联到开发版本的分支）。创建这些仓库的辅助工具应该使用类似git symbolic-ref HEAD refs/heads/debian/master一样的命令来更新HEAD到所需要的分支。

稳定版本

当包指向任何非开发版本（例如，稳定版本或者冻结的开发版本），应该使用目标发行版的代号命名的分支。比如Debian，就意味着debian/jessie, debian/wheezy, d/wheezy, debian/wheezy-backports，等。尽量避免以套件名称命名，因为可能随着时间而变化（stable变成oldstable等）。

安全更新和稳定更新应该在相关发行版的分支上处理。以Debian为例，wheezy-security或wheezy-proposed-updates应该在debian/wheezy分支做准备。如果要在两个仓库管理不同的版本包，，可以使用debian/wheezy-security和debian/wheezy-updates。

标记包版本

当发布一个Debian包的时候，打包者会创建并推送一个以<vendor>/<version>命名的标签（最好是签名的）。比如，（最好是签名的）。比如，一个Debian维护者发布一个2:1.2~rc1-1版本的包将会创建一个debian/2%1.2_rc1-1命名的标签，Ubuntu的打包者发布一个1.3-0ubuntu1版本的包将会使用ubuntu/1.3-0ubuntu1。这些标签要明确指向需要构建的提交。

管理上游源码

---

在Git中导入上游tar包

在Git的工作流中，从tar包中导入上游源码，这需要在“upstream”命名空间下操作。默认情况下，最后的upstream版本应该在upstream/latest分支下导入。并且当多个上游版本的包并发维护时，应创建所需的上游分支。

他们的名字需要基于被跟踪的上游主版本号，比如上游维护的一个稳定版本是1.2分支，在该分支发布1.2.x的小版本号时，这些版本应该在upstream/1.2.x分支中导入（.x后缀明确表明我们指的是一个分支，不是一个与上游1.2版本相对应的标签）。如果上游开发者使用代号来引用他们发布的版本，那么上游分支可以使用相应的代号。

辅助工具应该检测导入的上游版本何时低于upstream/latest中可用的最新版本，并且应创建新分支（基于历史中可用的仍然小于导入版本的最高版本）或选择另一个预先存在的上游分支。

通过Git标签导入上游版本

当打包分支是直接基于上游的Git分支的时候，上游通常会会为官方分支提供合适的Git标签。

如果帮助工具必须识别对应于给定上游版本的上游提交，他们应该能够通过查找以下Git标签找到它：upstream/<version>，<version>和v<version>。

upstream/<version>标签应该在打包者需要的时候创建：比如，当它基于Git快照执发布时，或者当上游使用的标签命名方案不遵循上述规则时。

关于pristine-tar

如果打包维护者使用pristine-tar工具逐字节的拷贝上游tar包，需要在pristine-tar分支中完成。

本地包

上述约定主要是针对当上游开发者和打包维护者不是同一伙人的时候。

当上游是Debian（或其衍生版本）的时候，上游厂商一般不使用<vendor>/为前缀（所有其他厂商也应该这样做）。主开发分支可以用master命名来代替目标发行版的代号（当然如果你想的话可以继续使用代号）。

当软件包作为一个本地包（例如，只有一个tar，没有上游代码和打包文件的却别），上游源码的概念以及upstream/*分支的都是没有意义的。请注意，即使上游供应商将包作为本机包提供，下游供应商仍然可以选择以非本地方式打包。

未完。。。