这个问题特别涉及在 GitHub 上托管自维护的 Debian 软件包的最佳实践。以下是我的困境：
- 通常建议不要将
debian文件夹放在源树中，以便其他发行版更容易使用。 - 所以我这么做了。我没有将
debian文件夹放在 GitHub 上的源代码树中。 - 然而，在构建 Debian 软件包时，构建机制预计
debian源树下会有一个文件夹。 - 这意味着我的 GitHub 存储库不能直接用于我的构建。这很麻烦，因为作为 Debian 自我维护者，我唯一的关注点是 Debian，而且我一直在构建我的 Debian 软件包，而不是为其他发行版构建。
- 我已经处理过这个问题，实际上我自己也有一个解决方案，但是当我在 GitHub 上标记发布时，发布 .tar.gz 文件将反映我上面的文件夹结构，这意味着来自 GitHub 的发布 .tar.gz 文件不是上游源代码的好候选。我对此没意见，但担心它可能会混淆其他人。
有没有什么简单的方法来管理它？例如，我可以告诉 GitHub 只为我的发布 .tar.gz 文件占用一个子文件夹吗？或者其他什么？我最不想做的事情就是将我当前的安排分成两部分，因为当我更改内容时，更改将在源和debian文件夹之间均匀分布。将它们分成两部分会失去这种内部连接/逻辑。
有什么建议吗？谢谢
答案1
嗯，每种方式都有优点和缺点。但从你的描述来看，单个开发人员以 Debian 为主要目标。我建议保留 Debian 原生软件包，我的意思是保留debian源代码树的一部分。即使对于拥有大量用户份额的主要操作系统，如 RPM。
我以前在一个资源不足的项目中遇到过类似的事情。我们设置了一个 Launchpad PPA（构建配方），它确实支持来自单独存储库或单独分支的源代码和打包，甚至支持 Debian 文件夹的自定义路径。它确实会在每次提交时进行构建。但随着时间的推移和代码的变化，特别是持续的重构，保持它的更新和运行变得非常费力。我们最终将其设置为按请求构建或在我们更新打包分支时构建，这通常意味着我们正在准备发布。
因此，如果您希望快速、持续地交付特定平台，请将其保留为代码的一部分。否则，请将打包分开并定期发布，就像 Debian 开发人员的工作流程一样。