这事情让我想想从哪里开始说起……应该还是从年初给DuckDB上RISC-V CI的时候说起（详见：当DuckDB遇上RISC-V），既然能构建CI，那构建Debian打包到源（Source）应该也不是问题。
在Github Discussions，我找到了一个讨论记录：
Deeature Request: Debian packaging #10071
而这个讨论指向了Debian社区（准确说法应该是Debian WNPP——Work-Needing and Prospective Packages）的DuckDB的ITP：
#1036922 - ITP: duckdb — fast, in-process analytical database - Debian Bug report logs
该ITP(Intent To Package)最早于2023年提出，从记录可以看到，那时的DuckDB版本号甚至还没到1.0，虽然ITP被提出了，但很显然并没有完成Debian Package打包。在邮件询问完相关人员，我开始接手相关打包事项
DuckDB的分发包被Debian社区的人给牛走了，没有我的事情了，此案结束🫤
流程问题
Debian对于包的贡献有一个非常复杂的流程，如果要接手一个ITP，正确做法应该是用reportbug发起RFA（Request for Adoption）声明你将接手打包工作，或者是RFP（Request for Package）让其他开发者关注
但当时在容器里，reportbug老是无法正常运转，所以我没做这个就直接开干了（虽然从结果上来说并没什么问题就是了😂）
基础打包套件
通过apt安装，已经过去太长时间，我现在只能把我想到的给记一下
sudo apt install wget build-essential debhelper devscripts dh-make fakeroot lintian quilt dpkg-dev dput debsign gnupg reportbug
针对DuckDB还需要以下依赖
sudo apt install cmake ninja-build libssl-dev g++
各类打包踩坑
DuckDB使用CMake构建，当时想着用LLM基本不会有什么大问题——但讲真25年年初的大模型还是不太给力，而确实有些情况超出预期
缓慢的编译速度&高内存消耗
debuild默认采用CMake+Make的组合编译，而Make如果不设置-j就是单线程运行，速度慢的令人发指😵
因此需要在rules中添加参数使用Ninja进行编译
dh $@ --buildsystem=cmake+ninja
内存消耗问题，则是因为自己是使用的WSL版Docker编译导致的——虽然我电脑内存是32GB，但要是同时运行多个网页外加QQ和微信，容器可能就会OOM导致崩溃。最后的解决方法是，移到学校的大服务器上编译，内存管够，速度肯定要比笔记本快得多😘
CRLF和LF问题
这其实是老问题了😂在Windows上做Linux相关工作，就不可避免会出现这种问题，但我没想到的是LLM生成的文件里默认是CRLF，这导致我上传Debian Mentors一堆爆红
解决方法无他：改为VSCode远程SSH进入编辑测试，而不是在Windows上改好文件再上传上去
Debian Salsa注册
这是Debian社区的Gitlab平台，需要进入Debian源的deb包基本都在上托管。其注册账号需要人工审核，因此从注册完成到登陆可能需要几天时间。一开始，我使用的是我的域名邮箱去注册（mocusez.site），等了很长时间，都没等来审核邮件，而我换成学校邮箱和Outlook却很快收到邮件——感觉应该是阿里邮箱关于收信的管理有问题，为此耽搁了几天的进度。
开源证书检查
这一块Debian要求比较高，所有源码，包括依赖在内，必须在copyright文件中标明所使用的开源证书（License）
一开始我用的是系统套件自带的licensecheck，但这个软件的运行速度实在是太慢了🥲后来看了Phil的Mentor页面，发现他用的是licenserecon进行检查，而我改用licenserecon以后检查速度确实快上不少
Git管理问题
最理想的情况是把Debian打包的相关信息上传到上游（也就是Github上DuckDB的仓库），但从Discussion的情况来看，DuckDB社区对于这个议题的积极性不是很高，所以放在Debian Salsa管理是个不错的选项
对此一般分成两个Branch：
一个主分支：放源码和Debian打包信息
一个Upstream分支：用于同步最新的源码
在经历几个月的实践下来，发现最理想的模式是Upstream分支实时拉取最新版本，然后cherry-pick，或直接将Debian打包信息复制进去然后commit
但这个方式总感觉还是不方便，可能以后还需要改进
文档Doc管理问题
Debian打包里需要一份纯文本的说明文件，应该是用于添加进Man Page，往Github Discussion发了信息没得到回复后（Request to Include Debian Manpage in Upstream Repository），暂且用duckdb --help的内容先顶上
小插曲：Debian Mentor
这里要感谢Phil Wyett提供的支持，在他的帮助下，我完成了对于DuckDB相对完整的deb打包流程，在写这篇Blog的时候，我准备以他的Mentor流程来介绍Debian打包的主意事项，但从最新的Blog来看（Debian activity and Debian Mentors）似乎他不再接手新的Mentor工作了（连带Debian Mentor的介绍页面一并删除），对此有些遗憾😥——如果你愿意进一步深挖，就会发现开源圈的水其实也很深
准备工作差不5月份就做完了，9月份的时候接到Otto Kekäläinen的邮件说愿意继续Review，但那时候我正在忙着做我毕业的主项目，腾不出手来继续推进打包，一直拖到11月底，Debian Mentors把我的打包删除，相关对话记录也找不到了，这件事就这样不了了之
结语
目前打包还在Debians Mentors挂着，大家感兴趣的可以看看
Debians Mentors页面：https://mentors.debian.net/package/duckdb/
Debian Salsa托管仓库：MocusEZ/duckdb