RubyMetric
deb 包构建 与 其自动构建和发布
我愿意维护deb软件包的ci自动打包与发布,但是deb软件包发布方式想要与大家一起讨论
- 在github release中提供deb软件包
- 利用github page 提供 apt 仓库(可以在提供的deb包中自动添加apt仓库) 这是我目前构思的发布方式,欢迎大家指正
@sanchuanhehe
非常高兴看到你愿意参与维护 .deb 包的 CI 自动打包与发布工作！这是 chsrc 项目分发长时间缺失的一部分，你的加入对我们帮助非常大 🙌
关于第一点
这也是大家所期望的，直接在 GitHub Releases 中发布，你在实践中遇到什么问题可以随时留言。
关于第二点
我们利用 GitHub Pages 托管的网站 https://chsrc.run 放在本仓库的 gh-site 分支：https://github.com/RubyMetric/chsrc/tree/gh-site/docs
APT 仓库是否会放一些元数据和 .deb 文件？如果要放比较大的或者经常变动的二进制文件，我们可另外开一个新仓库来托管。
@ccmywish 请问 https://github.com/RubyMetric/chsrc/tree/gh-site/docs/ 被映射到了 https://chsrc.run/ ,是这样的吗
https://github.com/RubyMetric/chsrc/tree/gh-site/docs/ 被映射到了 https://chsrc.run/ ，是这样的吗
是的
是否有镜像或cdn加速，国内用户使用是否稳定
没有镜像或CDN。只购买了 https://chsrc.run 这个域名，用的就是 GitHub Pages 服务。
有人报告过 https://chsrc.run 无法访问，所以稳定性说不准。
README 里写了如果访问不了 chsrc.run，就替换为 Gitee 上的等价地址。如果访问不稳定，可以开一个 Gitee 仓库来存储看看是否可行。
https://github.com/RubyMetric/chsrc/tree/gh-site/docs/ 被映射到了 https://chsrc.run/ ，是这样的吗
是的
是否有镜像或cdn加速，国内用户使用是否稳定
没有镜像或CDN。只购买了 https://chsrc.run 这个域名，用的就是 GitHub Pages 服务。
有人报告过 https://chsrc.run 无法访问，所以稳定性说不准。
README 里写了如果访问不了 chsrc.run，就替换为 Gitee 上的等价地址。如果访问不稳定，可以开一个 Gitee 仓库来存储看看是否可行。
能否之后配置下镜像或CDN(cdn就够了,甚至很多云服务商的cdn都是免费的),毕竟换源工具的源应该先保证稳定
研究了下，估计效果不太好。用国内的 CDN 应该还要备案，似乎有点麻烦。
APT 仓库有必要存在吗？单纯只是为了 apt install 更新方便吗？
我觉得只需要单纯分发 .deb 包到 GitHub Releases 中即可，没有那么多麻烦的维护工作。你觉得呢？
换成 Cloudflare 的 Free plan 了，不知道作用大不大。你有更好的方案吗？
我以前用cloudfare 的 free plan感觉还不错
研究了下，估计效果不太好。用国内的 CDN 应该还要备案，似乎有点麻烦。
APT 仓库有必要存在吗？单纯只是为了 apt install 更新方便吗？
我觉得只需要单纯分发 .deb 包到 GitHub Releases 中即可，没有那么多麻烦的维护工作。你觉得呢？
当然不止是apt install,最关键的是用户可以接受到更新,而不需要每个一段时间手动地去更新二进制包,为了贯彻NO UFO 原则: 不要乱丢文件到$HOME等目录，尤其是使用各种隐晦的文件名的同时为用户提供持久化的服务,我觉得依赖系统包管理器去更新配置是必要的
我的描述可能不是很清晰,但是您应该理解我的意思
现在我已经迁移 https://chsrc.run 到新的仓库：https://github.com/RubyMetric/chsrc.run
GitHub Pages 服务在其 main 分支上。
repo_folder 可以设置为 apt （目标效果是 https://chsrc.run/apt）
我不太清楚细节，你实现的那个 Action 可以直接放在本仓库，你另外用的那个 Action 是不是得放在 chsrc.run 仓库中？
现在我已经迁移 https://chsrc.run 到新的仓库：https://github.com/RubyMetric/chsrc.run
GitHub Pages 服务在其 main 分支上。
repo_folder可以设置为apt（目标效果是https://chsrc.run/apt）我不太清楚细节，你实现的那个 Action 可以直接放在本仓库，你另外用的那个 Action 是不是得放在 chsrc.run 仓库中？
是这样的,目前deb打包只支持amd64其它架构的编译我没能搞成功,另外需要考虑两个仓库action之间的联动,deb打包现在是release tag(vx.x.x这样子的或者手动触发(版本号格式x.x.x))触发
通过 push 到 gh-build 分支触发构建，已运行成功：
https://github.com/RubyMetric/chsrc/actions/runs/15660509357/job/44117489706
发布到了 pre 这个 release 中：
测试安装：
man 手册也可以正常打开。
现在略有问题的是 version，为了测试我先随意设置了个 9.9.9
@sanchuanhehe
我这两天基于你的工作，改动了许多细节，但是依旧是以你的工作成果为核心。和你沟通一下，方便快速明白现在的代码情况，以及为什么我改动，以及你之后修改代码对模糊不清的问题可以有一定的依据。
-
所有地方统一称呼为标准的小写
deb，之前我全部改为DEB了，是我想当然了，现在全面改回来 -
将
debian挪至pkg/deb，我看许多项目都在根目录放了debian，这应该是一种惯例，但是我觉得不妥，每增加一个新打包系统都要放在根目录的话，有些凌乱，而且构建的时候，生成的deb包会在源代码上一层目录，刚好在编辑器的视线之外，看不到 -
拆分两个 Makefile
- 根目录下的 Makefile 可以直接用
make build-deb和make clean-deb（调用下面的 Makefile），动词在前，和其他 target 一样 - pkg/deb/Makefile 是你为了兼容 compat 9 时引入的，target 名保持不变，名词在前，
make deb-buildmake deb-clean
现在我们开发的时候想要构建，一般从根目录就可以了，GitHub Actions 中也是直接调用的
make build-deb来构建，deb 包将生成在pkg/下（似乎debuild总是生成到CWD的上层目录）。 - 根目录下的 Makefile 可以直接用
-
补充文档、注释、文件头部的作者信息，增加可理解性
-
Actions workflow 的 step 能用中文名就用中文名，在 GitHub UI 里看的更清楚。能给中文注释就给，因为YAML文件，又混入shell脚本，可读性有点差，用中文显性区分，增加可维护性
-
Actions 里的上传到 release 的 action 已经被 deprecate 了，换成了现在广泛使用的一个第三方 action。其他 workflow 文件也在使用这个替换后的 action
现在 deb 包将和其他二进制一样，都在我推送到 gh-build 分支的时候构建，并上传到 pre release，名字固定为 chsrc_latest-1_amd64.，这样使得 URL 对用户来说一直保持不变：https://github.com/RubyMetric/chsrc/releases/download/pre/chsrc_latest-1_amd64.deb 。
在发布 release 的时候，也会触发构建，其文件名中带有版本号，是从源代码 chsrc-main.c 的版本信息中直接提取的，而非上面的 latest-1。但是现在还没测试，等 v0.2.2 发布的时候测一下。
README中已更新可以使用该方法安装。
我这两天基于你的工作，改动了许多细节，但是依旧是以你的工作成果为核心。和你沟通一下，方便快速明白现在的代码情况，以及为什么我改动，以及你之后修改代码对模糊不清的问题可以有一定的依据。
所有地方统一称呼为标准的小写
deb，之前我全部改为DEB了，是我想当然了，现在全面改回来将
debian挪至pkg/deb，我看许多项目都在根目录放了debian，这应该是一种惯例，但是我觉得不妥，每增加一个新打包系统都要放在根目录的话，有些凌乱，而且构建的时候，生成的deb包会在源代码上一层目录，刚好在编辑器的视线之外，看不到拆分两个 Makefile
- 根目录下的 Makefile 可以直接用
make build-deb和make clean-deb（调用下面的 Makefile），动词在前，和其他 target 一样- pkg/deb/Makefile 是你为了兼容 compat 9 时引入的，target 名保持不变，名词在前，
make deb-buildmake deb-clean现在我们开发的时候想要构建，一般从根目录就可以了，GitHub Actions 中也是直接调用的
make build-deb来构建，deb 包将生成在pkg/下（似乎debuild总是生成到CWD的上层目录）。补充文档、注释、文件头部的作者信息，增加可理解性
Actions workflow 的 step 能用中文名就用中文名，在 GitHub UI 里看的更清楚。能给中文注释就给，因为YAML文件，又混入shell脚本，可读性有点差，用中文显性区分，增加可维护性
Actions 里的上传到 release 的 action 已经被 deprecate 了，换成了现在广泛使用的一个第三方 action。其他 workflow 文件也在使用这个替换后的 action
现在 deb 包将和其他二进制一样，都在我推送到
gh-build分支的时候构建，并上传到prerelease，名字固定为chsrc_latest-1_amd64.，这样使得 URL 对用户来说一直保持不变：https://github.com/RubyMetric/chsrc/releases/download/pre/chsrc_latest-1_amd64.deb 。在发布 release 的时候，也会触发构建，其文件名中带有版本号，是从源代码
chsrc-main.c的版本信息中直接提取的，而非上面的latest-1。但是现在还没测试，等v0.2.2发布的时候测一下。README中已更新可以使用该方法安装。
感谢您的提醒,这对于我非常有帮助
2. 将
debian挪至pkg/deb，我看许多项目都在根目录放了debian，这应该是一种惯例，但是我觉得不妥，每增加一个新打包系统都要放在根目录的话，有些凌乱，而且构建的时候，生成的deb包会在源代码上一层目录，刚好在编辑器的视线之外，看不到
但是理顺这个目录调用关系有点晕
但是理顺这个目录调用关系有点晕
就是根目录 ./Makefile 调用 ./pkg/deb/Makefile
build-deb:
@$(MAKE) -C pkg/deb deb-build