gitpkg - 云端在线

程序：

您的姓名

gitpkg - 从指定的 git 修订版导出 Debian 源包

概要

gitpkg 科 [原始分支]

商品描述

If gitpkg 运行在 混帐(1) 指定单个“分支”的回购，然后它将执行 混帐-
档案 将该分支导出到 DEB_目录 目录。 如果软件包是 Debian 本地的
它将简单地从中创建一个源包。 如果该软件包具有 Debian 版本，则
预计它的原始 tarball 已经存在。 如果原始 tarball 没有
已经存在那么接下来会发生什么取决于 gitpkg.create-fake-orig
配置选项（如下所述）。

If gitpkg 使用指定的两个分支调用，然后将导出第一个分支
作为解压后的完整源代码，而第二个分支将被导出用于
原.tar.gz。 这允许对源的所有本地更改记录在结果中
如果存储库中存在原始上游分支，则为 diff.gz。 如果原始 tarball
'branch' 的版本已经存在，那么接下来会发生什么取决于
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 gitpkg.force-overwrite-orig 配置选项（如下所述）。

''科' 应该总是有一个 Debian的/ dir 并且可以是任何 树形的 对象是
被接受 git存档(1). 这 '原始分支'，如果提供，通常不应该有
Debian的/ 目录。

配置 配置

几乎所有的 gitpkg 配置使用 混帐配置(1) 现在。 下列
支持配置选项：

gitpkg.deb 目录
可以设置为覆盖导出包的默认目标目录。
默认为 '../deb 包'。 可用于挂钩脚本 DEB_目录。 这可能是
在命令行上用 --deb-目录=径 选项。

gitpkg.build-rootcmd
可以设置为覆盖用于获取包构建的 root 的默认命令
操作。 默认为 '假根'。 可用于挂钩脚本 BUILD_ROOTCMD.

gitpkg.prebuild-目标
可以设置为一个或多个目标 Debian/规则 将在之后调用
debian 源代码树已导出，但在构建源包之前。 一些
软件包可能会使用它来生成 autoconf 文件或类似文件，这应该
通常不在 repo 中，但应该在分布式包中。 这
使用 BUILD_ROOTCMD 调用目标。 这个钩子的一个常见用途是
调用包的 '清洁' 目标。 自 gitpkg 以来，默认情况下未设置此挂钩
0.18。 在此之前，它默认为干净目标。 可钩
脚本作为 预建目标.

gitpkg.orig 压缩器
可以设置为覆盖导出的 package.orig.tar 的默认压缩。
默认为 'GZIP'。 对于格式 3.0 包，有效值还包括 xz 和
bzip2. 可用于挂钩脚本 原点压缩器.

gitpkg.orig-压缩级别
要使用的可选压缩级别 gitpkg.orig 压缩器. 1 通常是
最快，9 通常是最小的，具有一切的精确细节
取决于所选的压缩器。 默认未设置（将使用
无论压缩器默认值是什么）。 可用于挂钩脚本
ORIG_COMPRESS_LEVEL.

gitpkg.deb 压缩器
可以设置为覆盖使用的默认压缩 dpkg-源(1) 用于出口
包。 默认（如果未设置）是使用任何 dpkg-源 想用。 为了
格式 3.0 包，有效值还包括 xz 和 bzip2. 可钩
脚本作为 DEB_压缩机.

gitpkg.deb-压缩级别
要使用的可选压缩级别 gitpkg.deb 压缩器. 1 通常是
最快，9 通常是最小的，具有一切的精确细节
取决于所选的压缩器。 默认未设置（将使用
不管 dpkg-源 默认为，当前为“9”）。 可用于挂钩脚本
DEB_COMPRESS_LEVEL.

gitpkg.dpkg-源
可以设置为逐字传递任意选项 dpkg-源(1) 构建时
源包。 谨慎使用，风险自负。 传递多个选项
至 dpkg-源 您必须多次设置此选项（即使用 混帐 配置 - 添加
对于每个选项）由于对选项的其他有趣的引用要求，例如
如“--format=3.0（本机）”。 默认为空。 可用于挂钩脚本作为
索引数组 DPKG_SOURCE_OPTS. 不要用它来设置 dpkg-源(1) -Z or -z
选项，它们应该改为使用 deb 压缩机 和 deb 压缩级别
选项分别。 这可能会在命令行上被覆盖
--dpkg-来源=ARG 选项，同样必须多次传递以设置
多种选择。

gitpkg.create-fake-orig
有时上游源代码和 debian 支持确实混合在一起
存储库的单个分支，但您仍然希望从中制作“非本地”包
它。 gitpkg 可以从这样的树中伪造原始 tarball，除了
debian/ 目录的内容。 将此选项设置为“true”会使
如果将单个树状传递给，则行为为默认值 gitpkg 并且没有相应的
找到原始压缩包。 将此选项设置为“false”将使 gitpkg 失败，
报告错误，如果传递了一个单一的 treeish 并且没有带有
正确的版本已经存在（并且没有被钩子脚本检索到
在需要之前）。 如果未设置此选项，则会提示用户
如果出现这种情况，正确的做法。 默认未设置。 可用的
将脚本挂钩为 创建_FAKE_ORIG.

gitpkg.force-overwrite-orig
此选项控制 gitpkg 如果'origbranch'树状是
指定并且对应的 'branch' 的 orig.tar 已经存在。 如果这
设置为“true”，则 orig.tar 将被 repo 源覆盖（以
重用现有的 orig.tar 只需调用 gitpkg 只有一个 debian 'branch'
您希望导出的树状）。 如果这被设置为'false'，那么这是一个硬错误
当 orig.tar 已经存在时，尝试再次导出上游源，并且
gitpkg 如果您尝试，将终止并责骂您。 如果未设置，系统会提示您
关于是否覆盖它，构建将继续使用哪个
在您选择的两个中。 默认未设置。 可用于挂钩脚本
FORCE_OVERWRITE_ORIG.

gitpkg.keep-解压源
此选项控制解压后的源目录是否保留
包导出和退出挂钩已成功完成。 如果这设置为
'true'，解压后的源代码将被保留。 如果设置为 'false' 或未设置，则
目录将被删除作为之前的最终操作 gitpkg 如果所有之前都退出
操作成功完成。 默认未设置。 可用于挂钩脚本
KEEP_UNPACKED_SOURCE. 这可能会在命令行上被覆盖
--keep-unpacked-source=布尔 选项（其中 'no' 或 'false' 不会保留它，任何
其他值，包括没有，将）。

SCRIPT 挂钩

可以在包构建期间从多个点调用用户定义的脚本
过程。 它们来源于 gitpkg 作为 bash shell 片段，在大多数情况下
subshel​​l，因此它们可以读取状态变量并执行外部操作，但不能更改
构建正在进行时的运行配置。 如果钩子返回非零
状态，然后 gitpkg 将被终止。 （确实终止 gitpkg 的钩子应该需要一些
注意不要留下太多的混乱，但也应该留下足够的线索完整
用户诊断和修复任何问题。 有用且信息丰富的错误消息
应该在以这种方式退出之前向 stderr 吠叫。）

钩子脚本可以安装在 repo 树之外的主机系统上，或者来自
存储库本身中的版本控制文件。 两种方法各有利弊
不同的用例。 钩子脚本由本地管理员激活，通过设置每个
相应 混帐配置(1) 带有要执行脚本路径的选项。 路径可能是
绝对或相对于调用该钩子的目录。 如果设置了钩子，
剧本 必须 调用时存在。 应注意仅启用它们以供使用
当挂钩到 repo 本身中的文件时，通过受信任的源树。 通常你应该
在每个回购的基础上启用它们 混帐配置(1) 而不是在 - 全球的 or - 系统
水平。

A 简要 警告 驳 越来越 上瘾：
您应该避免复杂的包装内挂钩布置成为出口必不可少的
你的包源。 如果您需要它们来正确创建特定的包，并且需要
与正在发布的源代码的严格版本绑定，它们对任何其他版本都没有用
完全打包......那么你很可能正在做某事，或几件事，相当
错误的。 否则你会在一些破碎的构建系统周围陷入如此深的泥潭，以至于你
不需要我告诉你这件事。 无论哪种方式，本地管理员都必须启用您的挂钩
在他们跑之前，所以如果你想对他人（和你自己）友好，那就保持
'正常' 包装工作严格在通常的包装构建工具内进行，并离开
gitpkg 为其他本地管理员免费挂钩以包装任何自动化 他们 需要
围绕事物。 如果包源的特定版本需要一些特定的
在第一个源包构建之前对其执行的操作，然后 预建目标
上面的选项很可能是您想要的，而不是这些钩子之一。 其他
人们可以稍后再次使用它，而无需使用 gitpkg。 目的是为了
这是为了帮助你。 对于 All Of You 的某些价值观。 所以一定要小心避免让它
如果没有调用钩子，就把其他人搞砸，和/或让他们知道他们需要什么
如果不是，请改为执行。 好的，有需要注意的倒钩，所以回到正题
再次：

钩 点
下面列出了可用的挂钩点，它们通常按大致顺序排列
调用：

gitpkg.package-CONFIG-钩
这个钩子在 repo 的顶级目录中运行 gitpkg 在，之前被调用
发生的任何操作，所有 混帐配置(1) 可供选择的来源
它。 钩子中没有关于包本身的详细信息
环境，甚至没有它的名字或版本，只有树-ish gitpkg
由用户传递，但钩子可能会根据
工作树的当前（可能是“脏”）内容 gitpkg 中被调用。

这个钩子能够修改 gitpkg 后续配置变量
操作。 如果需要，它可以在 repo 上执行操作，但是因为它需要
在它被调用之前提交到 repo，这可能没有那么有用
在这里实践。 基本上，它可以为所欲为，它只是一个外壳
剧本，其他一切都还没有真正开始，它已经被放到了最顶层
壳级 gitpkg.

它的操作不同于 管理员配置挂钩 只有一方面，路径
到这个钩子 必须 与 repo 的 TLD 和文件的修订相关
将采购的从“分支”树状结构中检出 gitpkg 是
要求出口。 该文件必须存在于给定路径的那个版本中。

可用于挂钩脚本 PACKAGE_CONFIG_HOOK.

gitpkg.admin-config-hook
这个钩子在 包配置挂钩 返回，并与它不同
仅通过从当前文件系统读取静态文件而不是通过读取静态文件来操作
从正在导出的存储库中提取版本控制的版本。

本地管理员可以使用它来覆盖任何特定于包的选项，即
可能已由 包配置挂钩，具有站点特定的配置。
这是一种策略控制，而不是安全控制。 当你放手时，安全就结束了
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 包配置挂钩 运行，这只是让你覆盖它而不必伪造
更改包钩子的新提交。

这是最后一个运行的钩子，可以修改 gitpkg 配置和
设置对以后的钩子可见的环境选项。 可钩
脚本作为 ADMIN_CONFIG_HOOK. 这可能会在命令行上被覆盖
--admin-config-hook=径 选项。

gitpkg.预导出钩子
这个钩子在 repo 的顶级目录中运行，在包名和
版本已经确定，最终的包配置包括
以前的钩子的任何调整。 它不能改变任何配置选项，
只对他们采取行动或终止 gitpkg.

这可用于执行诸如调用 pristine-tar 或预取现有 orig 之类的操作
来自某些外国来源的 tarball。 如果有的话，它可以对 repo 执行操作
这些是需要的，或者在我们之前需要完成的任何其他最后一分钟检查
实际上得到了导出我们想要打包的源的任务。

可用于挂钩脚本 PRE_EXPORT_HOOK.

gitpkg.deb 导出钩子
这个钩子运行在导出的 debian 源的顶级目录中，
从请求的源导出后立即 树形的和
紧接在之前 预建目标 被调用（如果提供）。 这不可以
更改任何配置选项，仅对它们进行操作或终止 gitpkg。 如果这
钩子终止 gitpkg, 导出的源码目录会留在系统上
供用户检查。 后续调用 gitpkg 对于同一个版本
虽然版本会覆盖它。 可用于挂钩脚本 DEB_EXPORT_HOOK.

gitpkg.orig-export-hook
此钩子在导出的“上游”源的顶级目录中运行，
从提供的源导出后立即 树形的和
在它被压缩成一个 tarball 之前。 它不能改变任何配置
选项，仅对它们采取行动或终止 gitpkg. 如果这个钩子终止 gitpkg,
导出的源目录将留在系统上供用户检查。
后续调用 gitpkg 对于相同的发布版本将覆盖它
虽然。

这个钩子是 仅由 如果上游“origbranch”实际上是从
存储库。 如果现有的 orig.tar 被发现或由某些人创建
较早的钩子（并且它没有被覆盖，请参阅 强制覆盖原点 多于），
那么这个钩子将执行的操作被假定已经发生
对于这个 tarball，它被跳过了。

假设这个钩子会在之前或之后执行是不安全的 债务-
出口挂钩，它实际上可能在某个时刻与它并行运行
未来。 他们都将在之后进入 出口前挂钩 返回，和 出口挂钩
直到（至少）在两者都返回之后才会开始。 还有什么发生在
其中，我们在现阶段没有做出任何坚定的承诺。

可用于挂钩脚本 ORIG_EXPORT_HOOK.

gitpkg.退出挂钩
这个钩子在包所在的目录中运行 .dsc 由 dpkg-
资源(1)、毕竟内部 gitpkg 操作已成功完成。 它是
更改任何配置选项，甚至终止都为时已晚 gitpkg 真。
你几乎可以从这个中做你喜欢做的事情，任何出错的地方
这是你自己做的。 可用于挂钩脚本 退出挂钩。 这可能是
在命令行上用 --退出挂钩=径 选项。

钩 环境
除了已经提供的变量之外，以下变量可用于钩子脚本
列为遮蔽a 混帐配置 上面的选项。 并非所有这些都有效/有用
所有钩子点，请参阅上面的钩子文档，了解适用于特定的例外情况
钩子。

GITPKG_HOOK_API
允许钩子脚本查询它们可用的接口。 只有两个
用“.”分隔的数字组件其中点右边的数字
每次我们添加一些钩子可能访问的新变量时都会增加，或者
添加一些新的旋钮，它可能会在现有界面没有改变的地方进行调整。
如果我们搞砸了，需要改变一些当前的界面，左边的数字
会被撞到。 当前 API 版本为 0.2

可提供 in API 版本 0.1
从 gitpkg 0.13 版开始，这些变量已可用于钩子

GITPKG_TREEISH
调用 gitpkg 导出的用户传递的 debian 'branch' tree-ish。

GITPKG_ORIG_TREEISH
调用 gitpkg 的“origbranch”树。 这将是空的，如果只有
指定了单个“分支”树。

DEB_源
要创建的源包的名称，没有任何版本控制。 正如在
来源：领域 dpkg-解析更改日志（1）。

DEB_版本
要创建的源包的版本，没有任何纪元。 正如在
.diff.gz 和 .dsc 文件的名称。

上游版本
创建的源包版本，没有任何 debian 版本。 正如所见
以原始压缩包的名义。 对于本机包，这将与
DEB_版本.

DEB_ORIG
要使用或创建的原始 tarball 的完整版本文件名。 这个变量是
没有 Debian 版本部分的本机软件包为空。

DEB_DSC
包的完整文件名 .dsc 将要或已经创建。

DEB_包
要传递到的 debianised 源代码树的目录名称 dpkg-源（1）。

回购目录
我们要从中导出的 git 存储库的顶级目录的绝对路径。
通常，如果你需要从你掉进去的树上看，你
可能（在）错误的（时间）做某事，但也有例外，并且正在
可以查询 混帐配置 选项就是其中之一。 这就是这个
现在。 见 回购配置助手 记录如下。 如果你这样做要小心
将其用于其他许多用途。

可提供 in API 版本 0.2
从 gitpkg 0.24 版开始，这些变量已可用于钩子

GITPKG_AOPTS
包含未被解析的命令行选项的关联数组 gitpkg
它本身可用于覆盖钩子的行为。 数组是键控的
在删除了“--”的选项名称上。 如果一个选项被传递
多次，只有最后传递的值将存储在此数组中。 为了
例：

$ gitpkg --my-option=foo --option2 --opt=oops --opt='bar baz'

会给：

${GITPKG_AOPTS[my-option]} = "foo"
${GITPKG_AOPTS[option2]} = ""
${GITPKG_AOPTS[opt]} = "bar baz"

GITPKG_IOPTS
包含未被解析的命令行选项的索引数组 gitpkg 本身
可用于覆盖钩子的行为。 该数组包含
传递的文字选项字符串，因此可用于访问选项
打算多次通过。 例如：

$ gitpkg --my-option=foo --option2 --opt=oops --opt='bar baz'

会给：

${GITPKG_IOPTS[0]} = "--my-option=foo"
${GITPKG_IOPTS[1]} = "--option2"
${GITPKG_IOPTS[2]} = "--opt=oops"
${GITPKG_IOPTS[3]} = "--opt=bar baz"

这个 选项的提取值 功能 回购配置助手 （详情见下文
它的）可用于进一步解析此数组以获得所有值
具体选项。

钩 自学资料库
有一些可用于各种任务的固定钩子脚本 /usr/share/gitpkg/挂钩
目前包括：

牛仔出口钩
一个简单的退出钩子，它发送导出的包以使用 牧童（1）。
要启用它：

$ git config gitpkg.exit-hook /usr/share/gitpkg/hooks/cowpoke-exit-hook

额外 混帐配置(1) 配置选项：

gitpkg-cowpoke-exit-hook.ask-first
如果'true'在调用前提示确认 牧童. 默认是只是
去做吧。

gitpkg-cowpoke-exit-hook.options
可能包括任何其他选项以逐字传递给 牧童. 通过多个
选项，设置多次，每个选项一次。 这可能是
在命令行上用 --牛仔=ARG 选项，同样
必须多次传递才能设置多个选项。

dpkg-buildpackage-退出挂钩
一个简单的退出钩子，用于在本地构建二进制包 dpkg-构建包(1). 到
启用它：

$ git config gitpkg.exit-hook /usr/share/gitpkg/hooks/dpkg-buildpackage-exit-hook

额外 混帐配置(1) 配置选项：

gitpkg-dpkg-buildpackage-exit-hook.ask-first
如果'true'在调用前提示确认 dpkg-构建包。 默认
就是去做。

gitpkg-dpkg-buildpackage-exit-hook.options
可能包括任何其他选项以逐字传递给 dpkg-构建包。 通过
多个选项，设置多次，每个选项一次。 这可能是
在命令行上用 --dpkg-bp=ARG 选项，同样
必须多次传递才能设置多个选项。

gitpkg-dpkg-buildpackage-exit-hook.build-log
如果设置'false'不保存构建过程的日志，默认是记录
一。

原始焦油出口前挂钩
使用原始焦油提取原始 tarball 的钩子。 要提取的原点是
由“分支”树的包版本决定。 要启用它：

$ git config gitpkg.pre-export-hook /usr/share/gitpkg/hooks/pristine-tar-pre-export-hook

如果在 repo 中找不到 pristine-tar 分支，那么 gitpkg 将被终止。

被子补丁-deb-export-hook
此挂钩读取适用于的修订范围列表 git-格式补丁（1）来自
文件 debian/源/git 补丁, 每行一个，并将它们导出到 Debian/补丁
以适合（格式 3.0）被子包的形式的目录。 它不是必需的
创建这样的包，但允许你分离出单独的补丁，但是你
请从由其他人创建的默认单个补丁中 dpkg-源.

要启用它：

$ git config gitpkg.deb-export-hook /usr/share/gitpkg/hooks/quilt-patches-deb-export-hook

内容 debian/源/git 补丁 可能包括注释（在任何行开始
带有#)、空行和一系列提交的表达式。 修订范围
可能包括 $DEB_VERSION, $UPSTREAM_VERSION, $DEB_REF or $UPSTREAM_REF。 第一
pair 将替换为要导出的包的版本，第二个
修改后与那些版本字符串配对 清理 git_ref 将它们重新映射到
合法的git 参考名称. 在大多数情况下，首选使用经过消毒的版本。
例如：

# 导出这两个树状树之间的所有提交，
# 基于要导出的包的版本。

上游/$UPSTREAM_REF..patches/$DEB_REF

debcherry-deb-出口挂钩
这个钩子调用 git-debcherry(1) 查找补丁并导出到上游源
以适合与（格式 3.0）被子包一起使用的形式。 它允许更多
自然（和自动）工作流程比上面的被子补丁挂钩通过搜索
对尚未应用到上游的打包分支所做的补丁。

要启用它：

$ git config gitpkg.deb-export-hook /usr/share/gitpkg/hooks/debcherry-deb-export-hook

为了使用这个钩子，一个 ${DEB_ORIG}.commit 必须创建文件，其中包含
存储库中导出的上游源的树状。 这将被创建
当您通过传递导出上游 tarball 时自动（如果此挂钩已启用）
都 科 和 原始分支 至 gitpkg，或者如果您使用 原始焦油出口前挂钩,
这确定了与 tarball 对应的适当提交。 如果你的上游
tarball 是使用其他一些机制创建的，您需要确保该文件是
创造了自己。

如果使用这个钩子，你可能希望在你的存储库中用一些东西来记录它
类似于中的文字 /usr/share/doc/gitpkg/examples/README.debcherry-export 作为一个
方便其他用户。 没有这个钩子，你的包仍然可以导出
启用，它只是不会将上游补丁单独分离成一个
被子系列。

钩 自学资料库 助手
这些是更琐碎的片段，用于可能由多个共享的操作
脚本。 还发现在 /usr/share/gitpkg/挂钩. 通常这些将来自其他
脚本而不是直接挂钩。

回购配置助手
提供一个简单的包装器`混帐 配置`，这确保它是从
存储库树，其中可以存储任何特定于存储库的配置选项。 对脚本有用
不是从 repo 树内部调用的，但确实有 混帐配置 选项
自己去查询。

提供 清理 git_ref 重新映射字符串的 shell 函数
在 git refname 中使用是非法的。

提供 选项的提取值 可用于提取一个 shell 函数
来自特定选项的值的数组 GITPKG_IOPTS.

有关功能的更详细文档，请参阅该文件本身的内容
它提供的。

互动性

如果你打算打电话 gitpkg 从你自己的脚本，那么你应该注意到有
默认情况下可能会交互提示的两种情况。 没有一个真正的理智
这些情况下的默认设置，因此最好询问用户并继续而不是进行
在他们打电话的可能情况下，他们再次开始整个过程 gitpkg
直接地。 有关详细信息，请参阅 gitpkg.force-overwrite-orig 和 gitpkg.create-fake-orig
上面的配置选项。 您应该将两者明确设置为您想要的行为
从他们那里如果 gitpkg 永远不应该变成互动的。

工作流程

虽然 gitpkg 明确不会试图将任何特定的工作流程程序强加给您
为了充分利用它，可能值得快速提及至少一个
在 git 中管理 Debian 软件包的简单方法。

一种常见的 repo 结构是在一个分支上保持原始的上游源，即
直接从上游存储库更新或通过将 tar 存档导入其中
定期，在另一个分支上使用 Debian 补丁源。 在这种情况下
从 tarball 准备新的上游版本的任务可能看起来有点像这样：

查看上游分支
$ cd myrepo
$ git checkout 上游

从 repo 中删除所有旧的上游文件
$ rm -rf $(除 .git 之外的所有文件)

将新的 tarball 解压缩到它们的位置
$ tar zxf $new_upstream.tar.gz

让 git 自己弄清楚什么是重命名的/新的/消失的。
确保你没有潜伏着 vim .swp 文件之类的东西
在树中仍然在这一点上。
$ git 添加。
$ git 提交 -a
$ git 标签 v$upstream_version

准备 Debian 分支
$ git 签出 debian
$ git 合并上游
$ $（更新变更日志和其他 debian 补丁等）
$ git 提交 -a
$ git 标签 v${upstream_version}-$debian_version

发布
$ gitpkg v${upstream_version}-$debian_version v$upstream_version
$ cd ../deb-packages/mypackage && dpkg-buildpackage ...

使用 onworks.net 服务在线使用 gitpkg