冷門但稀缺的技能：打包構建

最近我的朋友，Omnigres 的創始人尤里跟我聊天，他說想要招一個 PostgreSQL 打包專家 —— 當然具體的崗位名字，他起了個 EEE —— Extension Ecoystem Engineer，也就是 “擴展生態工程師”，倒是挺有意思。他發的這個 JD 吧，是公開的（https://github.com/omnigres/rfc/pull/2/files），我就直接貼在下面了。

稀缺的技能：Linux 打包

我覺得他的這個 JD 有點兒過分，DevRel + SRE + DBA + Building Engineer + PostgreSQL 專精 六邊形戰士，簡直是照著我寫的，但老馮還真沒見過其他有這種組合的人，所以我還是建議他老老實實找一個精通 Debian/EL 打包的構建工程師更實際一些…。但盡管如此，我認為難度還是挺大的，因為熟悉 “打包構建” 這個技能的人，咱都不能說用”稀缺“來形容了（更稀缺的應該是 DevRel）。

當然這里其實上下文語境，說的是 PostgreSQL 數據庫內核/擴展在 Linux 操作系統上的構建打包。主要是 C 和 C++，還有一些 Rust，Java，Go 之類的擴展與工具。打包的產物主要是 RPM 和 DEB 包，以 APT / YUM 軟件倉庫的形式交付。老馮認為，這是一個相當不為人知的高價值稀缺技能。

什么時候意識到這一點？

老馮第一次意識到構建打包這個事是在 2017 年，那時候我去聊 Pivotal，面試官就問了我一嘴，你會打包嗎，我們現在沒有會這個的。我就嘀咕，什么包？ RPM 包？嘿還真是。后來 Pivotal 出來的姚老板（YMatrix）也問過我這個事，你是不是打包構建比較熟悉，我們現在就特別缺這個，又讓我加深了印象。

后來其實我也看過許多國內國外的數據庫公司發布的軟件，打包這一塊確實慘不忍睹。比如之前的 Greenplum 是怎么交付給客戶的呢？是一個 CentOS 7.9 RPM 包。啊對，這個軟件它就提供一個 EL 7.9 RPM 包，您想要在 EL 8， EL9，或者 Ubuntu / Debian 或者其他 Linux 上運行？拜拜了您吶！

包括阿里云的 PolarDB for PG ，瀚高的 IvorySQL，本來也就是一兩個 EL RPM 包的樣子，在老馮的 Push 下總算是支持齊活主流 Linux 發行版了。MySQL 兼容的 OpenHalo 內核和 OrioleDB ，干脆就是我直接自己上替他們打包了。

構建打包的價值

打包這個技能很稀缺，但價值在哪里？其實你會發現，絕大多數終端用戶 并不在乎你是不是開源，他們在乎的是有沒有一個穩定可靠（最好免費）的二進制軟件包可以下載。就比如說 Greenplum 閉源了，但現在還時不時的有朋友來管我要 Greenplum 的 RPM 包。姚老板的 YMatrix （GP7 閉源分支）雖說是閉源商業軟件，但因為免費提供試用下載，大家也照樣能用著，誰管你開不開源。

更鮮活的例子是—— 源代碼其實還是在那里的，但是你把二進制產物（鏡像）給直接刪掉了，這就影響到終端用戶了 —— 你開不開源其實對用戶毛影響都沒有。真正會出現供應鏈卡脖子問題的，從來都不是軟件的源代碼，而是軟件制成品。

構建打包讓開源軟件自主可控

開源專家 Tison在他的公眾號文章《》和 《》其實深入聊過這個問題。結論就是：開源軟件是沒法斷供的，但是開源制品是可以斷供的 —— 想要安心使用開源軟件，最重要的還是擁有一份本地的軟件副本，或者建設自己的軟件倉庫。這里的核心就是打包構建。

就比如最近的 《》這件事，全世界幾乎所有鏡像站都跟 PGDG 上游失去同步了，停留在五個月前的過時版本。目前全世界只有德國的 XTOM，俄羅斯的 YANDEX，和老馮在中國的 PIGSTY 提供手動更新的 PGDG 最新軟件鏡像。

當然，鏡像站也只不過是同步一下人家做好的軟件二進制制成品，退一萬步講，如果 PGDG 不是停止增量同步而是直接徹底鎖死。那你要是想完全獨立從零搭建起一個軟件倉庫出來，針對 RISC-V，MIPS ，ARM 等亂七八糟的國產架構分門別類構建，那么打包構建依然是繞不過去的一道門檻。

打包和打包不一樣

當然有人會說，哎呀，都是開源軟件，你可以自己從源代碼編譯呀？這話說的不假，使用現代語言編寫的軟件已經針對打包構建流程做了很多優化了。比如，用 Go 語言寫的程序就非常容易構建打包，甚至還有 goreleaser 這樣的神器，可以一鍵幫跨平臺構建所有組合，生成 RPM / DEB 包，構建并推送 Docker 鏡像然后自動創建 GitHub Release ，而你讓 Vibe Coding 幫你實現這樣的工作流可能都要不了半個小時。

但是，我們說的并不是這些，而是像 Debian，PostgreSQL 這樣的巨無霸生態型項目（基本上基于 C / C++）。而且，構建打包 PostgreSQL 數據庫，可不是幾個 RPM 包就完事了。我這么說，現在我提供的10個發行版Linux發行版 x 5個PG大版本，再加上擴展和工具，總共有4萬多個左右的 RPM/DEB 包。

打包構建并不是一件輕松的工作：要處理好各種依賴，glibc，icu，openssl，PostGIS 帶著的一顆碩大無朋的依賴數。各種插件依賴的各種奇奇怪怪的系統庫，不同操作系統發行版甚至是大版本上的版本沖突， cmake，make，ninja，cargo 各種構建工具的用法，諸如此類。

你為什么不用Docker？

Docker 似乎是來 “解決” 打包構建的一種捷徑 —— 一次構建，到處運行 —— 才怪。我的意思是：用 Docker 你可以不用處理 Linux 操作系統大版本的組合因子（比如 el9, d12, u24 這種差異），但你依然要針對 PG 大版本，系統架構，以及幾百個擴展和他們的多個版本進行構建。第二，如果你去看 Postgres Docker 鏡像，就會發現其實它的 Dockerfile 里也還是用 apt install 去安裝 PGDG 的 DEB 包的…。Linux 軟件包是 Docker 鏡像的上游，而不是相反。

第三，PG 的擴展是它區別于其他數據庫的核心特色之一，而 Docker 容器鏡像至今也沒有辦法優雅解決 PostgreSQL 擴展插件持久化的問題 —— 你不知道用戶到底需要幾百個擴展中的哪一個，然而全部裝上又顯得過于臃腫和愚蠢。Alvaro 在這一方面正在進行一些前沿探索，但老馮感覺距離成熟實踐還有距離。

老馮怎么干起打包了？

老馮干打包這個事也就是從兩年前，那時候我要提供在 Pigsty 里自建 Supabase 的能力，但是 Supabase 用到了十幾個 PG 的擴展插件，這些擴展插件大部份都不在 PGDG 官方的二進制倉庫里面。我問了問 PGDG YUM 倉庫的維護者 Devrim，他說，Rust 寫的擴展永遠也進不了 PGDG 倉庫，因為編譯太慢了！所以老馮就只好自己上手，給這些擴展打好了 RPM 包。后來既然都打了 RPM 包，就干脆把 DEB 包也做了 —— 再后來，既然都已經支持了十幾個 PG 擴展，那干嘛不把 PGDG 官方倉庫不支持的兩百多個 PG 擴展也打包交付了？

一步一步走到今天，老馮獨立維護了一個 PostgreSQL 擴展倉庫，里面包含了 9 種風味的 PG 內核，以及兩百多款 PG 擴展（加上 PGDG 的總共 423 個可用擴展）。目前是 全世界 PG 生態收錄最多可用擴展制品的倉庫了。不謙虛的說，說起 PostgreSQL 打包構建，我和 Devrim（YUM 倉庫），Christoph（APT 倉庫），álvaro（OCI 倉庫），David Wheeler（PGXN） 算是這個賽道的頂級玩家了。

最直觀的例子就是，Supabase 作為目前 AI 賽道的當紅炸子雞與數據庫最大贏家，本應吸引大量廠商入局，但直到現在，有能力提供自建 Supabase 能力的開源 PostgreSQL 發行版，目前也只有老馮的 Pigsty （基于原生 Linux RPM/DEB），以及 Alvaro 的 StackGres（基于 OCI 鏡像與 Kubernetes ）

—— 因為我們都解決了這些 Supabase 專有擴展的構建打包分發問題。其實卡點就在這里，Supabase 即使把他的擴展源代碼開源出來（后面還要換 OrioleDB 內核），又有幾個人懂？又有幾個用戶有能力用起來？

說到底，單純懂 EL / Debian Linux 打包的工程師其實還是有一些的，但是同時熟悉 PostgreSQL 生態，能為 PostgreSQL 幾百個包在十幾個系統發行版構建的人確實是鳳毛麟角了。

懂打包的鳳毛麟角

在現實實踐中，老馮發現這個技能真的太稀缺了，就像尤里問我誰還懂這個，國內就甭說了，就算是全球，我知道的可能 ZoomboDB 那個作者（pgrx 作者）懂這個（被 ParadeDB 挖走了），別的我還真想不出來有誰能做好這個事情了。

比如說，PG 生態中，這么多擴展，能有有能力直接在發布的時候提供主流 Linux RPM / DEB 包的，我知道的就只有 ParadeDB 一家（pg_search），而他們會做這個事是因為他們發版太頻繁了，我實在懶得替他們打包了，所以手把手教他們應該怎么打 RPM/DEB 包。另一個會自己打包的是 pgroonga，timescaledb，citus，但是怎么說呢，打的包和 PGDG 規范不統一，而且經常缺這個缺那個 —— 比如 citus 一直就缺 ARM 的包，Timescale 則缺幾個特定的發行版，pgronnga 針對的是 Debian 自帶的 PG 去打的包 —— 諸如此類。

再比如說國內的數據庫廠商， 之前阿里云的 PolarDB for PG 和 IvorySQL 也就幾個 EL RPM 包，后來我使勁兒 push 他們，總算是 Pigsty 支持的 10 個主流操作系統發行版現在都有包了。我也幫他們解決過幾個低級打包錯誤。另外那個 MySQL 兼容的 OpenHalo，老馮干脆自己上了，替他們打好了 DEB/RPM 包。同理，Supabase 收購的 OrioleDB 看上去也沒有這個能力，所以我也替他們做了 RPM / DEB ，在 Pigsty 中開箱即用。

小結

很多時候，價值源于非共識，打包構建就屬于這種半瓶水外行看上去 “不就是編譯封裝一下”，但實際上相當稀缺的技能，脖子卡的嗷嗷叫的技能。

References