LankeOS v0.18 Release

Codename: Everest

"And we're out of beta, we're releasing on time!" —— Still Alive

核心变更 (Major Changes)

新功能和修复

0.18 的主题是**“桌面时代”**——LankeOS 终于从"能启动的发行版"进化到"能日常使用的桌面发行版"。

• KDE Plasma 6.7.4 完整桌面：从 BLFS 的 plasma 页面出发，构建了完整的 KDE 生态——70 个 KF6 框架 + 37 个 Plasma 精简集 + 18 个 Qt6 模块，外加 plasma-meta 元包一键安装。整个 KDE 桌面栈全部自建配方，依赖树经 docker 容器逐包验证。
• Plasma 精简策略：针对 Wayland-only 场景砍掉了 kwin-x11、polkit-kde-agent、oxygen 等 25 个非必要包；sddm 用 weston kiosk 模式跑 Wayland greeter。
• 新依赖链：为 Plasma 补齐了 libksysguard、libei、libqaccessibilityclient、sddm、weston、openxr、qt6 五模块等 20+ 个缺失依赖，全部 tarball 化规避 git+ 网络问题。
• farm 修复：SUID/owner 保留：修复 farm export/repack 以普通用户打包导致 SUID 丢失、owner 变 1000 的严重问题。现在全程 sudo tar（--no-same-owner 解压 + --numeric-owner 打包），彻底保留 root owner 和 SUID/SGID。
• farm 修复：hardlink 去重：修复解压重打包释放 hardlink 导致体积暴涨（git 包 331M→6M），配合 -22 --ultra 高压缩，完整 archive 稳定在 ~1.8G。
• lrepo-mgr 修复：修复 --wildcards '*metadata.json' 误匹配包内光标 metadata（breeze 的 SVG 光标）导致 7 个 plasma 包被跳过的问题。
• 包生态扩展：新增 55 个 tracker（KDE 全套 + 依赖库），版本追踪覆盖到 Plasma 6.7.4 / Qt6 6.11.1。
• 以上未记录的一堆修改：上面只是KDE系列，之前还新建了一堆kf-*包。同时libelf重命名为elfutils，打包了完整eu。

直观来说，本次新增约 200 个包的配方，其中 KDE 桌面栈是最大块头——从niri合成器到能启动 Plasma 会话，这是 LankeOS 第一次拥有完整图形桌面。

迁移指南

• 本次新增大量 KDE/Qt6 包，旧系统升级时 lpkg upgrade 会自动拉取新依赖（如 appstream 开启 appstream-qt 会引入 qt6-base）。
• sddm 默认配置是 Wayland 模式（DisplayServer=wayland），依赖树中的weston是必需的，如果sddm的greeter出现问题优先排查weston。
• 若升级后 sddm 无鼠标指针，检查 /usr/lib/sddm/sddm.conf.d/default.conf 是否含 CursorTheme=breeze_cursors。
• 由于libelf重命名，请使用sudo lpkg remove --force libelf+sudo lpkg install elfutils迁移

镜像体积变化

完整LiveISO在1.4G左右基本不变。

完整包 archive（lankeos_final_0.18_pkgs.tar.xz）约 1.8G，包含 633 个包。相比 0.17 增加 KDE 桌面栈，但通过 hardlink 去重 + 高压缩维持在合理体积。

稳定性与兼容性

本版本经过验证：

• KDE Plasma 6.7.4 完整桌面会话启动
• sddm Wayland greeter（weston kiosk）登录
• 完整包 archive 中每一个包都能安装

下一步计划 (Roadmap)

• kdenlive（视频编辑）（8/24完成）
• gimp（图像处理）（8/24完成）
• krita / Blender（krita 8/24完成，还差blender）

开发者的话

0.18 的主题是 “重量级桌面环境集成与正式版发布”。

（这似乎是名字最长的一个主题了？不过其值得，因为0.18是LankeOS的第一个正式Release）

从 0.17 的"能装能跑"到 0.18 的"有桌面"，相当于半个仓库规模的新增包考验了build farm和lpkg的稳定性，build farm的很多问题都在这些包的构建中显现，重大问题也都得以被修复

LankeOS 0.18，KDE Plasma 6.7.4 + Qt6 6.11.1 + 200 个新包。

（这一版的 KDE 栈是从 BLFS 页面 + Arch PKGBUILD 双重参考手搓的，build_deps 逐个对照 Arch 推导，全部构建通过）

—— Wtada233

8月26日 继续加重量级包：

• 添加70+依赖包，使用build farm验证通过
• 重构build farm的tracker部分
• 构建libreoffice（这玩意有100+依赖，其实我从0.14就想弄不过一直拖到了现在）
• 包规模达到753个
• 由于包archive太大，github release已经无法上传，改为archive.org了：（之前急中出错写错url了抱歉）
  • archive.org 存档链接

LankeOS v0.17 Release

Codename: Kangchenjunga

“所谓发行版就得发行，你发行了什么？”

“额...我发行了一堆cache被打包，依赖树不正确，多包拥有相同文件冲突，ABI混乱的垃圾包并紧急回滚了。”

核心变更 (Major Changes)

新功能和修复

一个独立发行版维护最大的难点就在于持续跟随上游维护软件包版本。在0.17之后，我认为LankeOS已经具备了这种能力。

• 新subproject：LankeOS Build Farm：依旧使用AI制作+我审核代码，在消耗30亿token之后LankeOS有了一个包含验证，仓库搭建，docker隔离构建和ABI变化传播rebuiuild，旧SONAME自动backup等功能的build farm
• farm功能：上游tracker支持：在0.17的开发过程中，我引入了使用yaml编写的tracker格式，支持多种template和自定义脚本格式，实测所有存在上游且有更新的包全都track完毕，接近200个包有更新。
• farm功能：声明式rebuild和build_ok记录：由于部分包不直接使用其依赖的ABI，但是依赖版本号（比如python库被安装到/usr/lib/python${MINOR}）所以farm引入了可自定义的通配rebuild，只要声明python升级时重建python-*就能避免问题。另外，farm会在一个LankeBUILD和对应json构建完成后使用其内容生成sha256 hash存入.build_ok，下次rebuild可以自动跳过没有改变的包。
• farm功能：旧SONAME自动备份和恢复：每个ABI出现breaking的包，旧的动态库都会被备份并在docker容器中恢复备份。效果为：同时存在两个动态库，旧程序使用旧动态库运行正常，新构建的程序链接指向新动态库的dev symlink正确构建。
• lpkg功能以及修复：新的lpkg 6.x使用libsolv完成依赖求解，同时修复之前版本失效的目录所有权记录。
• LankeOS功能：python的PEP 668规范使用：0.17使用PEP 668，禁止global安装python包，pip和所有基础python package都已经被打包，剩下的库可以通过venv使用。
• 杂项：虽然这个板块叫杂项，但是其实际上是最大的一类更新。所有的hacks.sh已经全部被删除，打包中的pycache被清理，默认PAM配置完善以及sshd默认提供systemd unit等细节部分是这个版本最多的优化。以及所有包的build_deps都已经被干净docker容器验证完全正确。

直观来说，本次更新的内容约等于10(0.10+0.14)，因为这个版本不仅再次重新完全自举（这是LankeOS的第三次自举，第一次是LFS，第二次是0.14，第三次是0.17）而且还顺便验证整个依赖树的完整性，更新约等于半个仓库的包，新增一堆python包和引入一个完整新farm架构。

迁移指南

• 本次更新修改了命名规范，libX和LSB/Linux-PAM这些都已经变为小写，请手动迁移。可以使用sed修改needed_so，deps，pkgs，files.db和provides.db这些lpkg数据。
• 本次更新把xml-parser重命名为了perl-xml-parser，请卸载并重新安装新的包。
• 由于迁移量较大，推荐下载新iso，使用当中的rootfs.sfs替换本地BASE的，重启并按照终端里的指导删除污染数据迁移。

镜像体积变化

我没统计，但是我估计变化不大，但是可用性一定会大幅提升——这个版本修复了一堆问题。

稳定性与兼容性

本版本经过在 Dell OptiPlex 5000 Micro（实体机） 上的严格验证：

• 新的包完美运行
• 所有包均可在build farm中构建
• 完整包archive中每一个包都能安装，ssh修复等正常运作

下一步计划 (Roadmap)

• 新增github cli，cloc等实用工具（KDE暂缓，我突然感觉没那个必要，我机器承受Chromium+Firefox的构建就已经很勉强了）

开发者的话

0.17 的主题是 “发行版工程”。

很多个人的从LFS开始的独立发行版都停在包的持续维护和更新这一关，好在LankeOS是顺利跨过了。

LankeOS 0.17，从0.16开始44410行diff，24405行新增，5089行删除

（其实仓库贡献者里的claude是claude code自动挂的Co-Authored-By，就算重写commit历史也一直在，我实际上是用的DeepSeek而不是claude，只是通过claude code调用）

—— Wtada233

LankeOS v0.16 Release

Codename: Lhotse

“是LankeOS火了吗？居然Docker Image上线一小时多就有50+下载！”

“其实只是爬虫发力了...”

核心变更 (Major Changes)

新功能和修复

0.15所新增的build_deps系统如同一把契科夫之枪（其实并不是，只是我在0.15的时候没研究出一个靠谱的build_deps生成方式）

而0.16是使其开火的时候了。

• 构建依赖自动生成：依旧vibe了一个小脚本，调OpenAI兼容的api自动使用AI来生成build_deps，实测正确率还可以，经过手动优化和批量编辑之后完全能用。
• gen_deps的metadata生成支持：原来gen_deps脚本只能修改打包好的.lpkg，现在支持自动填入LankeBUILD.json数据。
• 防火墙支持：nft+iptables（nftables后端）是这次顺便添加的（docker用了就顺便加入了，感觉也是个不错的功能）。
• 修改linux内核构建：添加一些内核模块和用户命名空间支持，大多数是为了防火墙和docker，同时更新内核release到2。
• 修复lpkg以及代码质量提高：修复lpkg在build_deps安装中会出现无法下载index警告的问题（其实际上是临时目录没有创建导致的）顺便借此优化了一下所有相关代码。
• 重磅功能：Docker！：添加整个docker的依赖树以及docker本体，同时在init脚本中把/var/lib/containerd挂载为ext4文件系统防止嵌套overlay导致的容器问题。
• LankeOS Base Image的Docker镜像上传：LankeOS全新自举的RootFS已经上传至Docker Hub作为未来可能的自动包构建workflow或者大家自己折腾的必要工具。

本次更新是LankeOS再一次挑战极限，事实证明系统的依赖树已经足以支撑chromium规模的软件包，接下来会引入KDE等。

迁移指南

• 本次更新没有引入breaking change，可以放心迁移（推荐在进入系统之后使用lpkg upgrade更新到最新软件集合，修复了较多问题）
• Docker因为是运行时通过unix socket连接所以并没有声明containerd等的依赖（这是预期行为，其并不是binary运行依赖），如果报错，你可以试着安装containerd。

镜像体积变化

ISO体积达到1.37 GiB，这个版本新增了一堆内核模块，一个防火墙和一整个Docker，并更新了Go版本，所以其实还算合理。（好像我每个版本都这样说...不过确实挺合理的）

稳定性与兼容性

本版本经过在 Dell OptiPlex 5000 Micro（实体机） 上的严格验证：

• 新的包完美运行，docker可以启动，甚至可以在LankeOS里运行LankeOS container
• 原来的所有包正常（这次对于nspr等包删除了静态库）
• 内核模块正确加载（对了，这次还及时止损瘦身了git仓库，原来给内核都提交上去了，按照内核的更新频率很快就会给仓库弄膨胀）

下一步计划 (Roadmap)

• 新增KDE系列软件包并完善包自动构建&发布系统

开发者的话

0.16 的主题是 “容器化与自动化构建的准备”。

在0.16，LankeOS首次有了其Docker Image，这意味着一个docker run+一个git clone就能获取一个完全确定的LankeOS构建环境，是下一步自动化构建的核心准备。

同时0.16也真正实现了可卸载arch的自举，在0.14，lpkg还是用的arch的docker构建；0.16引入docker之后，LankeOS所有包都可以在其自身系统构建了。这是一个较大的变化。

（主要还是源自我对自举的执念吧...之前一直就差一个包总觉得心里不踏实）

—— Wtada233

7月30日 更新+修复：

• 更新glibc到2.43
• 删除glibc和gcc所有可以删除的静态库
• 修复lpkg的strip会在部分边界情况损坏文件的问题
• 静态链接tini代替原来的docker-init实现环境无关的init使用

LankeOS v0.15 Release

Codename: Makalu

“这里是地狱吗？”

“不，这里只是一个试图用一块锁频2.5Ghz的CPU和USB3连接的硬盘加上16G内存构建chromium的可怜人的书房。”

核心变更 (Major Changes)

新功能和修复

看来说0.14是Golden Image说早了:L

• 修复构建：由于目前LankeOS只维护一个版本的jdk，所以新的LankeBUILD加入了jdk的/usr/bin软链接（java，javac等）修复了pciutils（没装headers和pkg-config文件）。
• 修复linux内核构建：0.14系统journal总是有噪音，是bluetooth-mesh疯狂失败并重启数百次。其实是linux内核没开用户态加密支持，新构建已修复。
• 修复lpkg以及代码质量提高：修复lpkg在边界情况中（比如重装应用覆盖文件）的4个bug；减少代码冗余，使用clang-format格式化代码。
• 桌面体验优化：添加xdg-utils，提供超链接处理等能力；构建chromium（这个重量级！构建过程中我进行了10次debug，花了30小时+构建时间，其实这个从0.13就开始弄了）
• 开发体验优化：引入build_deps系统，让构建依赖不再依赖hacks（我准备弄包CI，现在CI只是检查包语法和url，以后准备自动构建所以build_deps绝对有用）

本次更新是LankeOS再一次挑战极限，事实证明系统的依赖树已经足以支撑chromium规模的软件包，接下来会引入KDE等。

迁移指南

• 本次更新没有引入breaking change，可以放心迁移（推荐在进入系统之后使用lpkg upgrade更新到最新软件集合，修复了较多问题）

镜像体积变化

ISO体积并没有变大很多。问就是我修复了lpkg的一个bug，现在其strip体系会自动strip静态库了。另外默认使用firefox而不是chromium。这个版本只新增了其他的较小包到live。包括gn（方便快速构建Google生态软件和大型软件）

稳定性与兼容性

本版本经过在 Dell OptiPlex 5000 Micro（实体机） 上的严格验证：

• 新的正确性修复完美运行，chromium构建正常
• 新的rust-nightly构建成功，现在类似chromium的需要new rust feature的包也能构建了（LankeOS的nightly可能不会第一时间更新，问就是现在我维护精力有限，但是我尽力保持最新）
• chromium运行正常，终端里的超链接可以通过xdg-open正确跳转浏览器打开
• 所有其他软件全部正确运行

下一步计划 (Roadmap)

• 新增更多包并完善包自动构建系统（0.15-2已经新增Qt+OBS+xdg-desktop-portal和其后端）

开发者的话

0.15 的主题是 “大型软件的构建与用户体验优化”。

xdg-utils这玩意虽然也就几个脚本，但是我之前一直没弄的原因是其依赖树中有两个难缠的docbook-xsl和docbook-xml，我配置了半天/etc/xml/catalog才弄好这玩意...还没法关文档生成，强制依赖xmlto和这两个包。

对我而言这个release的难度相当于3个0.02（话说0.02啥时候成计量单位了...）主要是chromium的那一堆hacks，最后还是得靠arch的PKGBUILD才让我摸清了这个broken build-system的用法。

（现在更新体系已经可以工作，不用重装0.15，lpkg upgrade即可）

—— Wtada233

7月28日0.15-2更新：

• 新增Qt6基本包+qt6ct等工具
• 新增OBS录屏+推流软件，实测使用pipewire后端成功捕获屏幕内容
• 新增xdg-desktop-portal和其gnome以及gtk实现，为录屏做支持
• 修复部分配置错误和之前版本因为使用fish而不生效的profile.d
• 清理iso并重新打包

LankeOS v0.14 Release

Codename: K2

核心变更 (Major Changes)

正确性修复

本版本是LankeOS目前唯一一个没有发现任何重大问题的Golden Image:

• 修复构建参数：修复所有因为没有设置sysconfdir导致配置文件被安装到/usr/etc的包，对于systemd，更新到一个能在最新kernel headers下构建的版本（261）给gtk4开启x11 backend和最重要的vulkan功能；wireplumber开启introspection。
• 修复lpkg：基本完全重写了之前的lpkg原子事务功能，同时也backport到了0.13；0.14的lpkg支持更多构建模板变量。
• 使用动态链接：对于tcl，使用系统sqlite；把mesa-demos中默认fallback到自带的libdecor改为独立包。
• 修复不可用的包：在完整自举中，通过构建每个包，迁移中出现问题的坏包被顺利定位，并添加mkdir等修复步骤
• 修改rust构建：添加部分Arch Linux使用的rust patch，并将安装位置迁移到/usr（原来是/usr/local）使用stage2替代原来的stage1。
• sudo修复：原来的sudo没有安装PAM配置，导致其实际上无法在有PAM的系统重新构建并使用，新增PAM配置

本次与0.13及之前的增量添加功能不同。这一次更新，LankeOS停下来进行了重新自举，在自举过程中修复了包管理器和大多数包配置问题。

另外这次release从仓库删除了webkitgtk（没办法，我的机器构建一个firefox压力就足够大了，如果要经常自举那么webkitgtk是一大速度优化点：其没用，有firefox替代而且构建时间长）

迁移指南

• 本次更新没有引入breaking change，可以放心迁移（注意：如果你手动lpkg reinstall或者通过别的方式覆盖了sudo，可能导致部分问题，推荐在进入系统之后使用lpkg upgrade更新到最新软件集合）

镜像体积变化

ISO体积达到了 1.28GiB。

这次iso集成的软件新增了libdecor，gtk4和其所有依赖。

稳定性与兼容性

本版本经过在 Dell OptiPlex 5000 Micro（实体机） 上的严格验证：

• 新的正确性修复完美运行，/usr/etc已经删除
• 新的stage2 rust正常工作，成功重新构建firefox
• 自举脚本运行正常，完美构建所有包（仓库中的所有包已经替换为这次自举之后的版本）
• 自举之后所有软件全部正确运行

下一步计划 (Roadmap)

• 完善蓝牙协议栈（BlueZ + PipeWire 桥接）（0.14-2完成）

开发者的话

0.14 的主题是 “发行版工作流补全”。

之前的版本用户体验是有了——但是如果一个项目不维护，那么其只能叫LFS而不是一个Linux发行版。

虽然LankeOS之前有零散的软件包更新，但是一直没有过全量的重新自举。0.14补全了目前LankeOS技术最薄弱的部分。

对于用户体验更新，这次主要是bugfix，没有引入什么惊人的功能——如果出现了什么bug可以尝试使用lpkg upgrade

（现在更新体系已经在确立，在引入release系统之后可以很方便地发布hotfix，所以LankeOS已经步入稳定滚动更新阶段，以后版本号还是会发，但是大改动基本已经稳定，可以直接通过upgrade升级包而不需要使用最新镜像）

—— Wtada233

7月17日更新：添加全面的CI流程&优化构建文档

7月18日release修改：添加0.02-0.14的完整diff作为这次重大release的纪念品

7月23日较大更新

• 添加接近10个包，zoxide+fzf+eza+bat+tmux+jq+rg等基础工具
• 修复：在starship包中加入fish vendor conf取代原来的自带配置中硬编码starship
• 修复：为curl添加HTTP/2支持
• lpkg 修复：upgrade时的依赖解析功能添加和相关测试

7月25日修复&更新&兼容性

• 添加10+个包，现在LankeOS有305个包
• 添加libpulse和pipewire的pulseaudio兼容，支持目前主流Linux发行版三大音频栈的兼容性
• 添加bluez和blueman，写了好几个版本TODO的蓝牙终于好了
• 为systemd添加libseccomp支持，同时修复lpkg的部分问题（详情见仓库commits，主要是关于孤立目录移除的）

LankeOS v0.13 Release

Codename: Namchabarwa

“What linux distribution do you use? BTW, I use Arch”

“I use LankeOS.”

核心变更 (Major Changes)

软件生态的补齐

本版本让LankeOS完全具备我个人开发需要的所有常规程序

• 完善实用程序列表：构建mpv播放器，qemu虚拟机等常用工具
• 完善娱乐程序列表：构建noctalia shell用于bar，通知等核心桌面功能并加入btop

这次构建顺便送了一套我调好的niri dotfiles，感觉还不错:D

在虚拟机和实体机均完美运行niri和这套配置！（另外，目前虚拟机第一次初始化noctalia shell似乎会失败，我也不知道是竟态还是啥问题，总之我弄了个脚本自动在第一次启动的时候kill掉进程并重新启动，所以理论上现在一切正常）

early init重构

• 重构 之前版本的init一直不能检测跨版本替换rootfs.sfs导致的可能状态不一致，从0.12开始（在0.13开发过程中已经把这个提前完成的功能backport到了0.12的最后一个release）已经有官方的恢复功能可用，如果检测到lanke-release版本不一致，比如lower是0.13，upper是0.12，则能自动进入live环境，挂载DATA分区并提供恢复指引。

• 修复 之前的emergency shell能使用的命令太少，这次直接使用软链接提供了所有busybox subcommands的快捷形式

mesa 构建参数调整

• 修复 之前的mesa构建中没有开启virgl驱动，导致在虚拟机中niri等启动失败，这次重新构建mesa开启了支持

niri 上游源码问题修复

• 修复 我vibe coding了一个patch，解决niri过于挑剔环境的问题，现在LankeOS的niri支持软渲染和自动fallback而不是强制要求3D硬件加速。

镜像体积变化

ISO体积达到了 1.24GiB。

没事不亏。毕竟我往live里塞了一整套开发环境，现在其实LankeOS已经能在比ArchISO还小的iso里（ArchISO目前1.5GiB+）提供完成我日常所有开发工作的工具链了。

稳定性与兼容性

本版本经过在 Dell OptiPlex 5000 Micro（实体机） 上的严格验证：

• 基础工具链保持正常
• 开发环境添加Qemu，集成xwayland-satellite，niri可直接跑glxgears，原wayland无功能退化
• 新增的mpv解码正常
• 所有因mesa重建而依赖树出现问题导致需要重新构建的程序均通过构建且能正确使用

下一步计划 (Roadmap)

• 完善蓝牙协议栈（BlueZ + PipeWire 桥接）（别看这个挂了这么久，其实内核一边已经打通了，目前dmesg已经能看到蓝牙正确识别了）

开发者的话

0.13 的主题是 “即插即用的开发体验”。

在我意识到之前的固件精简得连nvidia都没有之后，为了便利的开发体验，我只好把firmware改为黑名单精简而不是白名单，保留了现代大多数固件，

虽然导致live膨胀（大约到了1G+）但是也带来了巨大的体验提升。当然，只有驱动还是不够的，所以我又构建了一堆我常用的软件，现在LankeOS的包规模接近300个了。

新增的软件有：btop（top替代），mpv播放器，qemu虚拟机，noctalia桌面shell(我懒得移植通知daemon了，直接用现成的了)，fish（懒人必备shell），starship（em.终端美化是必不可少的）甚至还有个jetbrains的nerd font以及一堆lib。

总体下来我觉得我可以连续用三天LankeOS不遇到功能缺失了，正好这几天我在重装arch（被之前的恶意AUR包影响到了，还好重要数据我迁移了）准备把所有数据迁移到LankeOS，包括我的ssh key，浏览器数据等。正好边使用边debug吧:D

—— Wtada233

7月10日更新 添加了vmware的硬件和svga支持

7月14日更新

• 底层重构，彻底重写 lpkg 的原子事务机制（成功消耗价值10元的token），实现事务日志功能，重写事务回滚机制。
• 修复 lpkg 的部分bug。
• lpkg 的测试增加到400+个，同时把lpkg更新到5.2.2的REL3（得益于 lpkg 的全新机制，现在已经有release功能，可以保持软件上游版本号的同时注明release）
• 添加脚本：LankeOS World Rebuild Helper，支持半自动自举（BTW，这就是0.14 "K2" 的主题：完整轻松自举）

LankeOS v0.12 Release

Codename: Himalaya

“什么才是真正的快乐？”

“Minecraft，启动！”

核心变更 (Major Changes)

Minecraft 的到来

本版本是LankeOS第一次成功运行一个知名游戏（没错，LankeOS甚至没有运行过Doom...But it actually can run doom.）

• 完善包列表：构建整个XWayland栈和OpenJDK 25
• 完善依赖树：为了XWayland，重新构建了gtk3等组件

这次构建把最后一门缺少的现代编程语言补齐，现在LankeOS已经是一个开箱即用的构建平台了！

Minecraft 1.21.8 搭配 BSL Shaders + 60 多个的优化与功能模组全部正常运行！

lpkg 修复与重构

• 目录所有者机制 模仿 Arch Linux 的方式进行了修改，并修复软链接安装等bug，移除多余的防止路径遍历（真奇怪，我写的时候在想些什么？这是一个包管理器！它就应该在根目录安装文件，为什么需要防止路径遍历的功能？）
• 测试 增加到180个左右

镜像体积变化

ISO体积达到了 987 MiB。

这是经过我努力压缩的一个结果，要知道一个没有压缩的 openjdk25 就有几百M了，这次只增加 30 MiB 是因为我删掉了几十MB的Python静态库，使用了gensquashfs（支持xz压缩level）代替mksquashfs（不支持）等一系列修改。

稳定性与兼容性

本版本经过在 Dell OptiPlex 5000 Micro（实体机） 上的严格验证：

• 基础工具链保持正常
• 开发环境添加Java，新构建的Xwayland栈正常，可直接跑glxgears，原wayland无功能退化
• Minecraft 1.21.8 运行稳定
• 所有依赖树出现问题导致需要重新构建的程序均通过构建且能正确使用

下一步计划 (Roadmap)

• 完善蓝牙协议栈（BlueZ + PipeWire 桥接）

开发者的话

0.12 的主题是 “日用组件补齐”。

从0.11的构建时开始，我就意识到：LankeOS 现在开发环境是很舒服了——但是总是缺东西，X应用无法运行，累了也最多看看视频没有游戏能玩...

所以我出手了（误）在我用完云星铁的免费时间之后，我痛下决心要在一天内弄好整个 Xwayland 和 Java 环境，跑起 Minecraft 1.21.8。

在0.12这个大版本，我在压缩大小（新增整个X图形栈和一个几百M的编程语言环境，只把镜像变大了37M！）和功能密度（直接跑Minecraft）之间取得了平衡，这是我目前最满意的一个版本，欢迎大家使用！

—— Wtada233

7月2日 修复：让 OpenJDK 使用动态链接，减小体积 2 MiB+ & 更改strip执行时机，确保jlink的hash校验不因为strip失败。

7月4日 新功能：扩展版本镜像，包含完整的Firmware，总大小在1.63GiB左右。同时继续发布原来的镜像。

7月5日 移除minimal iso，默认使用扩展版本；精简扩展版本Firmware，缩小扩展版本iso至大约1.18GiB

LankeOS v0.11 Release

Codename: Milestone

“啊！我是一个发行版维护者！我有16G内存！我有48G的Swap！内存！内存！天呐，下面使用者欣喜若狂诶，你好勇敢，你讲出你有16G内存！你用16G内存编译firefox！”

“你是不是疯了？”

核心变更 (Major Changes)

Firefox的到来

本版本完成了 LankeOS 历史上第一次完整的浏览器构建

• 完整浏览器：构建最新的Firefox 152.0
• 完善依赖树：为了Firefox的构建，目前已经构建了nodejs，ffmpeg，libx264，libx265等依赖
• 移除WebkitGTK的默认安装：上个版本默认安装的是WebkitGTK，因为其稳定性和功能弱点等现在已经被Firefox替代。从Live中移除但其仍然得到支持（通过在线repo）

这次构建同时完善了整个工具链，从汇编器（NASM,YASM）到Web开发（Node.JS）现在LankeOS一切齐全

包修复与依赖添加

• 所有introspection包 现在已经默认安装，GIR文件齐全
• 修复polkit和pipewire 适配目前带有PAM的系统，保证run0等所使用的鉴权机制正确运行；pipewire安装的alsa配置文件位置修改，确保两者正确对接

镜像体积变化

ISO体积达到了 900 MiB。

这其实很小了，毕竟系统里有
acl-2.3.2 alacritty-0.16.1 alsa-lib-1.2.15.3 at-spi2-core-2.56.4 attr-2.5.2 autoconf-2.72 automake-1.18.1 bash-5.3 bc-7.0.3 binutils-2.45 bison-3.8.2 boost-1.90.0 bzip2-1.0.8 cairo-1.18.4 cbindgen-0.29.4 cmake-4.2.3 coreutils-9.7 curl-8.11.1 dbus-1.16.2 dejagnu-1.6.3 diffutils-3.12 dosfstools-4.2 doxygen-1.17.0 duktape-2.7.0 e2fsprogs-1.47.3 ell-0.81 expat-2.7.1 expect-5.45.4 extra-cmake-modules-6.10.0 fastfetch-2.58.0 fcitx5-5.1.12 fcitx5-chinese-addons-5.1.11 ffmpeg-8.1.2 file-5.46 filesystem-1.1 findutils-4.10.0 firefox-152.0 flac-1.5.0 flex-2.6.4 fmt-11.0.2 font-noto-sans-cjk-2.004 fontconfig-2.16.0 freetype-2.13.3 fribidi-1.0.16 gawk-5.3.2 gcc-16.1.0 gdbm-1.26 gdk-pixbuf-2.42.12 gettext-0.26 giflib-5.2.2 git-2.48.0 glib-2.84.0 glib-networking-2.80.1 glibc-2.42 glslang-16.2.0 gmp-6.3.0 gnutls-3.8.11 gobject-introspection-1.84.0 gperf-3.3 graphene-1.10.8 grep-3.12 groff-1.23.0 grub-2.14 gtk3-3.24.52 gzip-1.14 harfbuzz-11.4.1 hwdata-0.403 iana-etc-20250807 icu-77.1 inetutils-2.6 intltool-0.51.0 iproute2-6.16.0 iso-codes-4.20.1 json-c-0.18.99 kbd-2.8.0 kmod-34.2 lcms2-2.18 less-679 libcap-2.76 libclc-22.1.7 libdisplay-info-0.3.0 libdrm-2.4.131 libedit-3.1 libelf-0.193 libepoxy-1.5.10 libevdev-1.13.6 libffi-3.5.2 libgcrypt-1.11.0 libglvnd-1.7.0 libgpg-error-1.54 libgudev-238 libime-1.1.10 libinput-1.30.901 libjpeg-turbo-3.1.1 libmp3lame-3.100 libndp-1.9 libnl-3.11.0 libnotify-0.8.8 libogg-1.3.6 libpciaccess-0.18.1 libpipeline-1.5.8 libpng-1.6.54 libpsl-0.21.5 libsecret-0.21.7 libsoup-3.6.6 libtasn1-4.19.0 libtiff-4.7.0 libtool-2.5.4 libunwind-22.1.7 libva-2.23.0 libvorbis-1.3.7 libwebp-1.5.0 libx264-20250815 libx265-4.1 libxcb-stub-1.0 libxcrypt-4.4.38 libxkbcommon-1.13.1 libxml2-2.12.6 libxslt-1.1.39 libyaml-0.2.5 linux-7.1.1 linux-firmware-1.0.1 Linux-PAM-1.7.2 llvm-22.1.7 lpkg-2.6.0 LSB-0.12 lua-5.5.0 lz4-1.10.0 m4-1.4.20 make-4.4.1 make-ca-1.16.1 man-db-2.13.1 man-pages-6.15 mesa-26.1.3 meson-1.8.3 mpc-1.3.1 mpfr-4.2.2 mtdev-1.1.7 nano-8.0 nasm-3.01 ncurses-6.5 nettle-3.10.2 NetworkManager-1.54.0 newt-0.52.24 nghttp2-1.64.0 ninja-1.13.1 nodejs-26.2.0 noto-sans-mono-cjk-sc-2.004 openjpeg-2.5.4 openssh-9.9 openssl-3.5.2 p11-kit-0.26.1 pango-1.56.4 patch-2.8 pcre2-10.47 perl-5.42.0 pipewire-1.6.2 pixman-0.46.4 pkgconf-2.5.1 polkit-127 popt-1.19 procps-ng-4.0.5 psmisc-23.7 python-3.13.7 readline-8.3 ruby-4.0.1 rust-1.96.0 rust-bindgen-0.72.1 seatd-0.9.2 sed-4.9 shadow-4.19.3 shared-mime-info-2.4 slang-2.3.3 SPIRV-Headers-1.4.350.1 SPIRV-LLVM-Translator-22.1.2 SPIRV-Tools-1.4.350.1 sqlite-3.49.1 sudo-1.9.17 sway-1.12 swaybg-1.2.1 systemd-257.8 tar-1.35 tcl-8.6.16 texinfo-7.2 unifdef-2.12 unzip-6.0 util-linux-2.41.1 vim-9.1.1629 vulkan-headers-1.4.341 vulkan-loader-1.4.341 wayland-1.24.0 wayland-protocols-1.47 wget-1.25.0 which-2.21 wireplumber-0.5.14 wlroots-0.20.0 wpa_supplicant-2.11 xkeyboard-config-2.45 xml-parser-2.47 xz-5.8.1 yasm-1.3.0 zip-3.0 zlib-1.3.1 zstd-1.5.7

稳定性与兼容性

本版本经过在 Dell OptiPlex 5000 Micro（实体机） 上的严格验证：

• 基础工具链正常
• 开发环境完美，可直接构建Firefox
• Firefox 浏览器运行稳定，可以流畅访问BiliBili
• 所有依赖树出现问题导致需要重新构建的程序均通过构建且能正确使用

下一步计划 (Roadmap)

• 为仓库添加更多包
• 完善蓝牙协议栈（BlueZ + PipeWire 桥接）

开发者的话

0.11 的主题是 “真正可用”。

从0.08到0.09的自举时开始，我就一直有这么一种感觉：这系统怎么这么难以操作？为什么这个WebkitGTK总是崩溃？为什么这个MiniBrowser无法播放视频？为什么权限验证总是有问题？

在0.10的开发中，我意识到了问题所在：我的构建太理想化且遗漏了一些东西。其假设PipeWire能正确安装alsa conf，但是实际上pipewire会往/usr/share而不是/etc放config，导致对接alsa失败。

以及我忘记在有PAM之后把polkit切换到PAM支持，导致其出现兼容问题，run0等失效等问题

在0.11这个大版本，我努力把LankeOS打造成了我用着舒服的样子，欢迎大家使用！

—— Wtada233

6月27日 紧急更新：打包fcitx5-gtk，修复firefox的中文输入；filesystem职责分离，添加filesystem的LankeBUILD

6月28日 大重构：

• lpkg 2.6.5 → 3.0.1（Breaking: 依赖系统语义变更，needed_so 合并入 deps）
• needed_so 校验：安装前检查每个 SONAME 有提供者，无提供者拒绝安装
• SIGINT 防护：类 pacman 双段式优雅退出
• gen_deps 重构：输出版本约束 → 输出 needed_so + provides（SONAME 级别）
• 索引格式扩展：第 4 段 needed_so
• 测试 127 个（新增 26）

6月29日 支持添加：

• 添加intel_media_driver，完善Firefox硬件加速支持
• 删除live中的无用包
• 在live中加入alsa-utils，pciutils和libva-utils，便于诊断系统状态和进行操作
• 在live中加入go，整个编程语言工具链已经完整了！C/C++/Rust/Python/Awk/Lua/Perl/Go/Shell
• Live大小压不住了，到了950MiB！不过毕竟又新增了一门编程语言，还可以接受。

LankeOS v0.10 Release

Codename: Alps

“哥们，你发行版依赖树有些发紫，是不是LLVM不好？”

“你发行版没我的稳定你信吗”

核心变更 (Major Changes)

编译器链全面更新：GCC 16.1.0 + LLVM 22.1.7

本版本完成了 LankeOS 历史上最惊险的一次工具链自举升级。起因是 Linux 内核 7.1.1 的一次 breaking change（突然删除了 scc.h 头文件），导致旧版 GCC 15.2.0 和 LLVM 21.1.7 双双过时，无法重新编译，我系统里的binary成了孤本，仓库里的构建脚本成了死包。面对“旧编译器已死”的绝境，我实施了一次外科手术式的升级：

• GCC 从 15.2.0 → 16.1.0：利用仅存的 15.2 二进制成功自举 16.1.0，并彻底摆脱了对已删除内核头文件的依赖。
• LLVM 从 21.1.7 → 22.1.7：在 GCC 16 的基础上重建 LLVM 全家桶，并且完成了期待已久的 “拆包”操作：
  • 将 libunwind 和 libclc 从 LLVM Monorepo 中独立拆分，作为系统级基础库单独维护。
  • 激进清理静态库：趁此机会彻底移除了 LLVM 和 Clang 的所有能安全删除的 .a 静态库文件，只保留动态库（.so）和开发头文件以及极少数的静态库。这大幅缩减了无用磁盘占用，并强制所有软件动态链接，避免了未来因静态库 ABI 过时引发的隐蔽问题。
• 完整依赖树重生：为了配合新工具链，我们重新构建了整个图形栈和语言生态：
  • Mesa（链接新 LLVM 22）
  • Rust（利用新 LLVM 重新编译，确保内部 LLVM 版本一致）
  • SPIRV-LLVM-Translator / SPIRV-Tools / SPIRV-Headers / glslang（间接）（全部指向新 LLVM 的 ABI）
  • 同时，部分其他组件也进行了针对性重编译，避免因 libstdc++ ABI 变化导致的运行时崩溃。

这次构建标志着 LankeOS 具备了 “在自身内核破坏性变更下仍能实现工具链自愈” 的强悍生命力。

包拆分与依赖净化

• llvm 包拆分为 llvm、libunwind、libclc：遵循“单一职责”原则，现在你可以独立升级异常处理库和 OpenCL 编译器，而无需拖拽整个 LLVM。
• 所有 SPIRV 相关工具 现进行更新，适配最新llvm

lpkg 更新：

• lpkg 包管理器更新到2.6.0，使用AI工具优化代码质量并修复一些注释问题，新增subcommand：depend，模拟依赖解析
  • depend 用法：install/remove/abibreak pkgname [-all]

镜像体积变化

得益于本次 LLVM 拆包，ISO 体积从 0.09 的 798 MiB 成功下降至 793 MiB。

这背后其实是一场我蓄谋已久（这里好像不应该用这个词吧...碎碎念中）的巧妙胜利。直接暴力删除静态库（.a）是行不通的——LLVM 的 CMake 文件将静态库写死，任何依赖 LLVM 的包（如 Mesa、SPIRV-Translator）只要调用CMake找LLVM就会因找不到 .a 文件而直接报错退出。
唯一的解法是启用 install-distribution 目标（参考Arch Linux的PKGBUILD），但这意味着要维护一个安装组件列表，单是 libclc 没有独立安装目标这一点，就足以让整个默认安装流程卡死。
拆包才是破局的关键。把 libclc 和 libunwind 从 LLVM 本体中请出去后，LLVM 本体终于可以毫无顾虑地使用分发安装目标，仅安装动态库和头文件，优雅地绕过了那个陷阱。而 libclc 在自己的独立包中正常安装、自得其乐。

系统规格更新 (Technical Specs)

稳定性与兼容性

本版本经过在 Dell OptiPlex 5000 Micro（实体机） 上的严格验证：

• GCC 16 和 Clang 22 均可正常编译内核模块和用户态程序
• Mesa 驱动正确链接新 LLVM，GPU 加速正常
• WebKitGTK 浏览器运行稳定，无段错误
• Rust 项目可正常构建（如 ripgrep、alacritty）
• SPIRV 工具链可编译 Vulkan 着色器
• 所有依赖新 LLVM 的程序均通过 ldd 验证指向 libLLVM-22.so，无残留旧库引用

下一步计划 (Roadmap)

• 引入 系统快照/回滚 机制，避免未来再次陷入“编译器孤本”窘境
• 完善蓝牙协议栈（BlueZ + PulseAudio 桥接）

开发者的话

0.10 的主题是 “绝地自救”。

说实话，当我在几天前的下午例行更新linux内核的LankeBUILD.json并重建时，我还没有意识到这场灾难，直到我试图给LLVM拆包时发现无法构建——因为我的 GCC 15.2 和 LLVM 21 都依赖这个头文件，而它们本身已经无法重新构建（源码里依旧是写死了scc.h）。

唯一的出路是：用旧 GCC 15.2 去构建 GCC 16.1（后者已修复该问题），然后用 GCC 16 去构建 LLVM 22，再用 LLVM 22 重构建整个图形栈。每一步都不能错，环境必须绝对隔离，否则 CMake 会抓到旧头文件导致编译失败。

我花了整整一天时间，在 Tmux 里开了一堆窗口，每一步都紧盯构建日志确保没有一个被吞掉当作正常日志的error（点名批评LLVM，在报错之后居然还跑了几分钟直到我手动Ctrl+C），还得随时在我的小主机上防范OOM。最后终于好了...

关于那几百个静态库的删除：
这其实是被逼出来的副作用，但也是我早就想干的事。每次看到 LLVM 构建目录下那数百个 .a 文件列队经过时，它们都在嘲笑我的镜像体积。以前不敢动，是因为 LLVM 把它们写死，暴力删除只会让 Mesa 和 SPIRV-Translator 直接翻脸不认人。
这次借着拆包的机会，终于把 libclc 和 libunwind 请了出去，让 LLVM 本体安安心心用了 install-distribution 目标（这里Arch的贡献真的是义父级别的了！感谢Arch送的PKGBUILD）。没了那几个“钉子户”的阻碍，静态库们终于被集体清退。ISO 不增反减到 793 MiB，算是这次苦战中最解气的意外甜点了。

这次经历让我更加坚定：一个真正的独立发行版，必须能在自身工具链被“斩首”时，依然能从源码重新长出新的工具链。 0.10 给了我们这份信心。

—— Wtada233
（彩蛋：猜猜Alps是什么？）

LankeOS v0.09 Release

Codename: Lanke++

从这一版本开始，LankeOS 不再只是一个精简的桌面原型，而是拥有了完整的图形应用生态和编程语言支持。
另外为了Dogfooding的闭环，我专门在实体机安装了LankeOS。现在已经在运行0.08版本了。0.09的所有开发都在其上进行

核心变更 (Major Changes)

浏览器正式入驻

本版本最显著的变化：WebKitGTK 作为第一个图形化浏览器被纳入系统。

这意味着 LankeOS 现在可以：

• 渲染现代网页 (HTML5/CSS3/JavaScript)
• 支持 WebKit 引擎的图形应用
• 为后续图形化软件（如邮件客户端、RSS阅读器）奠定基础

搭配 Wayland + GTK4，浏览器运行流畅，GPU 加速正常。

GTK4 全栈落地

在 0.08 中，GTK4 并未完整集成。本版本补齐了 GTK4 及其全部依赖：

• gtk4 本身
• gstreamer 及 gst-plugins-base、gst-plugins-bad 多媒体插件
• libsoup (HTTP 客户端库)
• libsecret (密钥存储)
• libpsl (公共后缀列表)
• glib-networking (TLS/SSL 支持)
• libepoxy (OpenGL 函数指针管理)
• libgcrypt / libgpg-error (加密支持)

现在，任何 GTK4 应用都可以开箱即用，无需额外依赖。

Ruby 语言支持加入

继 Python、Perl、Lua 之后，Ruby 4.0.1 正式进入官方软件仓库。

为后续 Ruby 生态工具（如 Jekyll、Rails 等）扫清障碍。

多媒体与图像处理能力增强

新增：

• gstreamer 全套多媒体框架（播放、编码、流处理）
• libtiff / openjpeg / lcms2（高级图像格式与色彩管理）
• libyaml（YAML 解析，用于配置和元数据）

构建与打包工具链改进

• lpkg 升级到 2.1.0，支持更灵活的包版本处理
• 新增 unifdef（预处理工具）和 nghttp2（HTTP/2 库）

软件包新增列表

相比 0.08，0.09 新增了以下软件包：

同时，lpkg 从 2.0.1 升级到 2.1.0。

系统规格更新 (Technical Specs)

稳定性与兼容性

本版本在 0.08 的实体机验证基础上，进一步测试了：

• GTK4 应用运行（如 WebKitGTK 浏览器）
• 多媒体播放（通过 GStreamer）
• Ruby 脚本执行
• 网络 HTTPS 请求（libsoup + glib-networking）
• 图像格式扩展（TIFF/JPEG2000）

所有新增组件均已在 Dell OptiPlex 5000 Micro 上通过稳定性测试。

镜像体积变化

由于新增了大量图形和多媒体的库，ISO 镜像从 0.08 的 748 MiB 增长到 798 MiB。

这标志 LankeOS 正式从“最小可用”走向“功能丰富”的桌面发行版。

下一步计划 (Roadmap)

• 集成 Thunderbird 或 Geary 作为邮件客户端
• 完善蓝牙（BlueZ + PulseAudio 桥接）
• 引入 Qt 支持，扩展应用生态

开发者的话

0.09 的主题是“生态大爆发”。如果说 0.08 让 LankeOS 在实体机上跑了起来，那么 0.09 就是让它真正能用起来——能看网页、看视频。能运行 GTK 应用、能写 Ruby 脚本。

这次最大的工程挑战是 GTK4 及其依赖的递归构建。GTK4 依赖 GStreamer、libsoup、libsecret 等，而它们又各自依赖加密库、HTTP/2 库等。整个构建图比预期复杂得多，但最终所有依赖都在 LankeBUILD 中稳定通过。

WebKitGTK 的集成更是耗时，它是整个系统里构建最慢的软件包之一（仅次于 LLVM），但最终看到浏览器窗口在 Sway 中弹出的那一刻，一切都值了。

LankeOS 正在从一个 LFS 实验品，变成一个真正能日常使用的独立发行版。

—— Wtada233