2020 年，借鑒沙箱/容器的技術(shù)方案，玲瓏原型的核心開發(fā)悄然完成；

2022 年，作為 deepin 發(fā)行版未來的核心特性，玲瓏隨 deepin v23 預(yù)覽版共同發(fā)布，初步具備可用性；

2023 年，我們將玲瓏項目代碼、玲瓏官網(wǎng)、玲瓏商店等資產(chǎn)捐贈給開放原子開源基金會，欲匯聚更多產(chǎn)業(yè)力量，攜手推動玲瓏發(fā)展，加速生態(tài)建設(shè)……

那么到底何為“玲瓏”？它從哪里來？又要到哪里去？接下來，此文為你一一揭秘。

前言：軟件包管理器的演進(jìn)

Linux 操作系統(tǒng)一直以其開源性質(zhì)和靈活性而聞名，而要使 Linux 系統(tǒng)能夠順利安裝并運行所需的軟件，最關(guān)鍵的部分就是軟件包管理器。

顧名思義，Linux 軟件包管理器是一種在 Linux 操作系統(tǒng)上用于安裝、更新和卸載軟件包的工具。它的歷史可以追溯到上世紀(jì) 90 年代，此時 Linux 正處于起步階段，軟件的安裝必須手動下載源代碼并編譯，這對非技術(shù)用戶來說是一項繁瑣且困難的任務(wù)。

這種情況下，先后催生了 dpkg 和 rpm，然而由于不能自動解決依賴關(guān)系，其使用起來依舊不便。

直到 Debian 的 apt、Red Hat 的 up2date 的發(fā)布，包管理器可用性有了很大的提升。它們采用了一種被稱為“依賴關(guān)系解決器”的算法，能夠自動解決軟件包之間的依賴關(guān)系，從而簡化軟件的安裝和升級過程。但這在另一方面大大增加了復(fù)雜度，維護(hù)者們需要非常謹(jǐn)慎小心地處理，稍有不慎就會陷入“依賴地獄”，導(dǎo)致軟件包系統(tǒng)發(fā)生故障。

此外，還有許多其他的軟件包管理器，如 yum、portage 和 pacman 等。包管理器的多樣性給用戶帶來了更多選擇，但缺點也十分顯著：它們的軟件包無法互通，這意味著一款軟件要在其他發(fā)行版上使用，可能需要被重復(fù)打包。

隨著 Linux 內(nèi)核對容器的支持、Docker的誕生，Snap、Flatpak 等一批容器思想的包管理器也開始嶄露頭角。這類格式的軟件包與系統(tǒng)環(huán)境幾乎完全解耦，不再依賴系統(tǒng)上的庫文件（AppImage 也是如此），應(yīng)用分發(fā)開始逐步變得簡單起來。但磁盤、內(nèi)存占用較高，啟動時間被不斷延長等問題也隨之而來，至今仍未被解決。

探索：“玲瓏”應(yīng)運而生

deepin 自 2015 年放棄基于 Ubuntu 作為上游，選擇 Ubuntu 的非商業(yè)上游社區(qū) Debian 作為研發(fā)的基礎(chǔ)起，我們便收到了眾多用戶關(guān)于軟件包管理上的問題反饋，常見的有：

系統(tǒng)上能用的應(yīng)用太少，可用的應(yīng)用版本太老；
系統(tǒng)更新后，某些應(yīng)用無法正常使用；
從其他來源獲取某些應(yīng)用軟件安裝后，包管理器無法正常工作，甚至系統(tǒng)無法繼續(xù)使用。

以上這些問題有一個共性原因：依賴關(guān)系綁定太強(qiáng)。因系統(tǒng)底層庫的關(guān)系，應(yīng)用無法隨意更新，在底層庫有接口變動時，應(yīng)用需要重新適配才能正常工作。

在意識到這些問題后，我們開始嘗試使用新的軟件包管理器。

在 deepin 上適配 Snap：由于 Snap 在除 Ubuntu 系統(tǒng)環(huán)境外有諸多兼容性問題，遂放棄。
將部分自研應(yīng)用轉(zhuǎn)化為 AppImage：AppImage 有著不錯的可移植性，這些應(yīng)用可以很輕松地在其他發(fā)行版上使用。但它沒有集中的倉庫存儲和軟件包管理功能，也不提供 Snap、Flatpak 同一級別的沙箱，安全性無法保障，不適合作為操作系統(tǒng)的默認(rèn)軟件包管理方式。
2017年，deepin 對 Flatpak 格式進(jìn)行了跟進(jìn)，完成了 100 的軟件包構(gòu)建工作，后因其應(yīng)用體積較大，磁盤占用過多、Bug 修復(fù)緩慢等各種原因沒有繼續(xù)適配。

在經(jīng)歷過種種“折騰”后，基于對各類包管理器的了解，我們決定自己設(shè)計一套軟件包管理系統(tǒng)。

在經(jīng)過 3 個多月的技術(shù)調(diào)研，1 年多的原型驗證、技術(shù)方案完善和產(chǎn)品打磨后，最終一套先進(jìn)的解決方案——“玲瓏”應(yīng)運而生。