draft v2 in zh

Author: ruaharico

content/developer/packaging/basics.zh.md

@@ -34,17 +34,15 @@ AOSC OS 是滚动发行版，这意味着 AOSC OS 整体发行时不使用版本
 
 Ciel 的主要功能为管理独立的 AOSC OS 构建环境（通称 BuildKit），因此 Ciel 不一定需要在 AOSC OS 上运行。如果您使用的是 Arch Linux，可以通过 AUR 安装 Ciel。
 
-接下来，我们可以开始配置 Ciel 工作区了。该教程使用 `~/ciel` 作为 Ciel 工作区路径进行演示。注意：Ciel 需要使用 `root` 运行，且不能在 Docker 容器中运行；在创建工作区的过程中，需要从 GitHub 下载内容，请确保您的网络环境能够顺畅地访问 GitHub。
+接下来，我们可以开始配置 Ciel 工作区了。**注意：Ciel 需要使用 `root` 身份运行（您可以使用 `sudo -i` 命令以提权（此时会进入root shell，`~`会指向`/root`），也可在每条命令前添加`sudo `（此时`~`不会改变））；在创建工作区的过程中，需要从 GitHub 下载内容，请确保您的网络环境能够顺畅地访问 GitHub。**
 
-请运行如下几个命令并跟随屏幕指示配置 Ciel 工作区。在向导询问目标架构时（Target Architecture），选择当前这台设备的处理器架构；询问维护者信息时（Maintainer Information）时，参照示例填写自己的信息；其余选项使用默认值即可；询问是否需要创建新实例时（Do you want to add a new instance now?），请选择是，并创建一个名为 `main` 的实例。
+请先在合适的地方新建一个文件夹（文件夹所在的分区建议留出 10 GB 或以上的可用空间）并切换到这个文件夹，然后运行以下命令，开始配置 Ciel 工作区。在向导询问目标架构时（Target Architecture），选择当前这台设备的处理器架构；询问维护者信息时（Maintainer Information）时，参照示例填写自己的信息；其余选项使用默认值即可；询问是否需要创建新实例时（Do you want to add a new instance now?），请选择是，并创建一个名为 `main` 的实例。
 
 ``` bash
-mkdir ~/ciel
-cd ~/ciel
 ciel new
 ```
 
-工作区配置完成后，我们建议更新 BuildKit 环境。并且，在今后的
+工作区配置完成后，我们建议使用以下命令更新 BuildKit 环境。建议在每次打包前或每天打包前更新 BuildKit 环境，虽然 Ciel 现在会自动执行更新，但由于此时是在构建时执行一次更新，相关更新会随着构建完成后容器的回滚而丢失，下次构建时会带来额外的不必要的时间消耗。
 
 ``` bash
 # 如果这一步耗时很长，您可以考虑通过 "ciel config" 设置 APT 源配置 (sources.list)。
@@ -205,11 +203,17 @@ ciel build -i main hello
 
 很简单，对吧？这是因为 Autobuild4 的自动探测功能判断出这个包需要使用 `autotools`（即 `./configure && make && make install`）流程进行构建。
 
-## Git 操作规范
+然后，在 Ciel 的工作区目录下，你就能在相关的 OUTPUT 文件夹内看到构建出来的 `.deb` 软件包。此时，你可以在 AOSC OS 双击安装 / 使用 oma 安装 / 使用 dpkg 安装，测试这个软件包是否可以正常工作。如果它不能正常工作，（……）。
 
-软件包构建完成后，接下来要做的就是提交你的构建脚本了。AOSC OS 对 Git 提交说明有着相当严格的要求，下面介绍的是几个常用格式。我们在[软件包样式指南 (Package Styling Manual)](@/developer/packaging/package-styling-manual.zh.md) 描述了全部打包风格规范，建议择时阅读。
+## Git 提交
 
-如需往树内增加软件包，Git 提交信息应遵循如下格式：
+在简单尝试之后，您就可以开始尝试打包自己想要为 AOSC OS 新增或更新的软件包了。如果是为 AOSC OS 新增一个软件包，需要考虑的要素会比上文中打包 GNU Hello时要多，例如运行时依赖与构建依赖；如果遇到问题，可以在社区群组或者社区论坛询问。
+
+用户打包一个软件包，并不等于一定要上传到 AOSC OS主树。但我们建议，只要软件是允许 AOSC OS 维护者打包与重分发的，那么欢迎把软件包提交到主树，参与丰富和完善 AOSC OS 的软件仓库。相对地，个别软件并不允许 AOSC OS 维护者打包与重分发（例如个别专有软件和“免费商用”但不允许重分发的字体等），或者不适合继续提供给用户（例如已有后续项目，原项目不再更新，前后具有继承关系），如您仍要使用，您可以只为自己打包，只要不把相关分支上传到主树即可。
+
+软件包构建完成并测试可用后，就可以开始提交你的构建脚本了。AOSC OS 对 Git 提交说明有着相当严格的要求，下面介绍的是几个常用格式。我们在[软件包样式指南 (Package Styling Manual)](@/developer/packaging/package-styling-manual.zh.md) 描述了全部打包风格规范，建议择时阅读。
+
+如需往树内增加软件包，Git 提交信息应遵循如下格式，且原则上不应出现多笔提交（如有，则需使用 `git rebase -i` 进入可视化变基，以将多笔提交合并为一笔）：
 
 ```
 $PKG_NAME: new, $VER
@@ -244,11 +248,11 @@ bash: update to 5.2
 
 ## 上传软件包
 
-在成功构建软件包后，您就可以开始上传软件包了。您可以将本地 Git 分支（如 `hello-2.12.1-new`）推送至您的 fork，随后在主树创建拉取请求（Pull Request, PR），按模板要求填入信息。
+软件包构建完成并测试可用，且成功使用 Git 执行提交（commit）操作后，您可以将主树 fork 到自己的 GitHub 上，将本地 Git 分支（如 `hello-2.12.1-new`）推送至您的 fork，随后在主树创建拉取请求（Pull Request, PR），按模板要求填入信息。
 
 接下来，请静候 PR 审核。社区的贡献者会审阅并提出修改意见（如有），在修改和测试通过后，社区的贡献者会通过您的 PR 并合入 stable 分支。最后，您就可以使用自动化设施构建软件包，将新的软件包或软件包更新推送给所有用户。目前，软件包的上传与推送工作由自动化设施完成，相关内容请见[使用自动化设施构建软件包](@/developer/packaging/buildit-bot.zh.md)。
 
-（是否提及“一次提交即可成为贡献者”？）在成为贡献者后，您可以将本地 Git 分支直接推送到主树，之后使用自动化设施创建 PR、测试构建软件包、自行安装并测试、生成审计报告（/dickens），等待其他贡献者审阅与通过 PR后，将软件包合入 stable 分支并**再次**构建软件包。
+对 AOSC OS 主树贡献一次提交后，即可成为贡献者。在成为贡献者后，您可以将本地 Git 分支直接推送到主树，之后使用自动化设施创建 PR、测试构建软件包，自行安装并测试、生成审计报告（/dickens），等待其他贡献者审阅与通过 PR后，将软件包合入 stable 分支并**再次**构建软件包。
 
 # 结语