deepin 辛苦楼主去扒源码。我昨晚重新构建了一下，desktop又正常了，后面又重构了几次，都没再出现问题，也许是偶发性事件。
7分钟之后更新：
活见鬼，昨晚我试了几次都没问题，睡觉之前，最后构建了一次，早上来办公室安装，快捷方式依然有问题。。。
还是想不明白这种路径是怎么产生的，能否给一下这些信息
中文 
ll-cli --versionlinglong/filesystem/diff/usr/share/applications中对应的原始desktop内容linglong/output/binary/share/applications中对应的desktop内容也可以整个工程压缩了传上来
deepin 辛苦楼主去扒源码。我昨晚重新构建了一下，desktop又正常了，后面又重构了几次，都没再出现问题，也许是偶发性事件。
7分钟之后更新：
活见鬼，昨晚我试了几次都没问题，睡觉之前，最后构建了一次，早上来办公室安装，快捷方式依然有问题。。。
似乎要破案了，ostree_repo.cpp还会对desktop进行第三次处理，而且应该在提交到仓库时发生，这里干了不该干的事情：
https://github.com/OpenAtom-Linyaps/linyaps/blob/cb3a81d50b381bcf2ae21645ded397a482fba5f0/libs/linglong/src/linglong/repo/ostree_repo.cpp#L2457-L2514
QString buildDesktopExec(QString origin, const QString &appID) noexcept
{
auto newExec = QString{ "%1 run %2 " }.arg(LINGLONG_CLIENT_PATH, appID);
if (origin.isEmpty()) {
Q_ASSERT(false);
return newExec;
}
auto *begin = origin.begin();
while (true) {
if (begin == origin.end()) {
break;
}
begin = std::find(begin, origin.end(), '%');
if (begin == origin.end()) {
break;
}
auto *next = begin + 1;
if (next == origin.end()) {
break;
}
if (*next == '%') {
begin = next + 1;
continue;
}
QString code{ *next };
switch (next->toLatin1()) {
case 'f':
[[fallthrough]];
case 'F': {
origin.insert(next - origin.begin(), '%');
auto tmp = QString{ "--file %%1 -- -- %2" }.arg(std::move(code), std::move(origin));
newExec.append(tmp);
return newExec;
}
case 'u':
[[fallthrough]];
case 'U': {
origin.insert(next - origin.begin(), '%');
auto tmp = QString{ "--url %%1 -- -- %2" }.arg(std::move(code), std::move(origin));
newExec.append(tmp);
return newExec;
}
default: {
qDebug() << "no need to mapping" << *next;
} break;
}
break;
}
return newExec.append(QString{ "-- %1" }.arg(origin));
}
这里面
auto tmp = QString{ "--file %%1 -- -- %2" }.arg(std::move(code), std::move(origin));
的--file 和错误的Exec指令内容对上了
Exec=/usr/bin/ll-cli run org.qgis.qgis.stable.linyaps --file %F -- /opt/apps/org.qgis.qgis.stable.linyaps/files/entrypoint.sh qgis %%F`
fix: can not start app normally when there are extra parameters · OpenAtom-Linyaps/linyaps@4f20d6c
两周前这里还是单横线
auto tmp = QString{ "--file %%1 -- %2" }.arg(std::move(code), std::move(origin));
deepin 还是想不明白这种路径是怎么产生的，能否给一下这些信息
ll-cli --versionlinglong/filesystem/diff/usr/share/applications中对应的原始desktop内容linglong/output/binary/share/applications中对应的desktop内容也可以整个工程压缩了传上来
玲珑版本 ll-cli --version ：昨天晚上deepin25更挂了，玲珑版本是1.7.1或者是1.7.3
linglong/filesystem/diff/usr/share/applications中对应的原始desktop内容：
有多个desktop，只有这个带执行参数 %F 的有问题。另外就是Terminal=true之后，你说的那个bug问题。
# linglong/filesystem/diff/usr/share/applications/org.qgis.qgis.desktop
[Desktop Entry]
...
Icon=qgis
TryExec=qgis
Exec=qgis %F
Terminal=false
StartupNotify=false
...
linglong/output/binary/share/applications中对应的desktop内容：
# linglong/output/binary/entries/share/applications/org.qgis.qgis.desktop
[Desktop Entry]
...
Icon=qgis
TryExec=qgis
Exec=/usr/bin/ll-cli run org.qgis.qgis.stable.linyaps -- /opt/apps/org.qgis.qgis.stable.linyaps/files/entrypoint.sh qgis %F
Terminal=false
StartupNotify=false
...
出问题的layer文件：
比较奇怪的是，在output目录中的desktop是正常的，但是使用ll-cli install *.layer之后，在主机的上生成的desktop就会多内容。
deepin 刚才得空比较了一下，玲珑版本1.7.5。
在diff、output的desktop都是没问题的，就是最后用ll-cli install *.layer的时候，在主机生成的/var/lib/linglong/entries/share/applications目录下的org.qgis.qgis.desktop有问题，而且仅有这个执行字段值有%F的desktop有问题，另外生成的一个Python3.12的desktop执行字段值不带%F就没问题。
问题可能发生在导出为layer或者ll-cli install的过程。
diff_dir-org.qgis.qgis.desktop.txt
deepin 刚才得空比较了一下，玲珑版本1.7.5。
在diff、output的desktop都是没问题的，就是最后用ll-cli install *.layer的时候，在主机生成的/var/lib/linglong/entries/share/applications目录下的org.qgis.qgis.desktop有问题，而且仅有这个执行字段值有%F的desktop有问题，另外生成的一个Python3.12的desktop执行字段值不带%F就没问题。
问题可能发生在导出为layer或者ll-cli install的过程。
diff_dir-org.qgis.qgis.desktop.txt
对的，他这个代码在导出layer或ll-cli导入layer时触发，我用的1.7.4，这个版本还没有引入这个bug。
具体发生在哪个时机还不能确定，不敢升级新版本。
这个操作的目的似乎是想让ll-cli接收文件或URL参数，然后让ll-cli去替换启动命令中的%F %U等占位符，
难道desktop本身不支持替换%参数吗？实在不明白这是要干啥
现在我已经在killer中添加的layer相关的子命令，可以绕过builder构建和生成layer，大幅降低磁盘损耗，后面再测试下玲珑新版bug的情况。
deepin 玲珑版本 ll-cli --version ：昨天晚上deepin25更挂了，玲珑版本是1.7.1或者是1.7.3
linglong/filesystem/diff/usr/share/applications中对应的原始desktop内容：
有多个desktop，只有这个带执行参数 %F 的有问题。另外就是Terminal=true之后，你说的那个bug问题。
# linglong/filesystem/diff/usr/share/applications/org.qgis.qgis.desktop
[Desktop Entry]
...
Icon=qgis
TryExec=qgis
Exec=qgis %F
Terminal=false
StartupNotify=false
...
linglong/output/binary/share/applications中对应的desktop内容：
# linglong/output/binary/entries/share/applications/org.qgis.qgis.desktop
[Desktop Entry]
...
Icon=qgis
TryExec=qgis
Exec=/usr/bin/ll-cli run org.qgis.qgis.stable.linyaps -- /opt/apps/org.qgis.qgis.stable.linyaps/files/entrypoint.sh qgis %F
Terminal=false
StartupNotify=false
...
出问题的layer文件：
比较奇怪的是，在output目录中的desktop是正常的，但是使用ll-cli install *.layer之后，在主机的上生成的desktop就会多内容。
网盘文件中的layer解包看里面的desktop是正常的：
TryExec=ll-cli
Exec=/usr/bin/ll-cli run org.qgis.qgis.stable.linyaps -- /opt/apps/org.qgis.qgis.stable.linyaps/files/entrypoint.sh qgis %F
那完蛋了，这个bug在玲珑包管理器里，想修也修不了，只能他们自己修了。
deepin 网盘文件中的layer解包看里面的desktop是正常的：
TryExec=ll-cli
Exec=/usr/bin/ll-cli run org.qgis.qgis.stable.linyaps -- /opt/apps/org.qgis.qgis.stable.linyaps/files/entrypoint.sh qgis %F
那完蛋了，这个bug在玲珑包管理器里，想修也修不了，只能他们自己修了。
那就先凑合着用吧。目前来看，用玲珑打包之后，之前用ACE兼容环境或者distrobox使用QGIS不明卡顿的问题已经解决了，性能貌似也有所提升。
其他的都是小问题。
非常感谢楼主的开发！
deepin 大佬，支持导出为uab吗，而不是layer文件
deepin 大佬，支持导出为uab吗，而不是layer文件
要导出uab可以对着killer创建的项目用ll-builder build+ll-builder export两个命令进行构建和导出，不过uab体积过于巨大，实用性很一般。
导出layer文件则可以用killer内置的layer子命令进行处理，速度更快，空间占用和硬盘损耗也更小。
deepin 要导出uab可以对着killer创建的项目用ll-builder build+ll-builder export两个命令进行构建和导出，不过uab体积过于巨大，实用性很一般。
导出layer文件则可以用killer内置的layer子命令进行处理，速度更快，空间占用和硬盘损耗也更小。
uab的体积应该已经优化了，跟appimage差不多了，后续可以推荐大家默认导出为uab
deepin uab的体积应该已经优化了，跟appimage差不多了，后续可以推荐大家默认导出为uab
uab能优化么？我打包一个空的玲珑项目为uab，输出体积高达400M，用layer文件只有40KB。
论优化，我有一个大胆的想法。
Popular Ranking
ChangePopular Events
More
Certificate verification failed
ll-killer-go - 玲珑杀手Go
前言
本项目是 Linglong Killer Self-Service (ll-killer 玲珑杀手) 的Go语言重构版本，将原本构建阶段的shell脚本重新用Go实现以更可靠地在 本地离线运行 ，并添加了许多增强功能。
项目主页：https://github.com/System233/ll-killer-go
ll-killer-go是什么
本文主要包括
ll-killer-go的简单介绍和一个Ubuntu源的GIMP应用的迁移示例教程。v1.4.x 革命性更新 ： 新增的
layer子命令详解项目简介
ll-killer-go是一款专为解决玲珑容器应用构建问题而设计的命令行工具。它帮助开发者快速创建、构建和生成玲珑容器应用项目，同时提供一整套辅助构建与调试功能。使用该工具，用户可以在玲珑容器中获得与传统容器（如docker）类似的构建体验，包括对特权命令的支持和apt安装等功能，免去了手动解压软件包（如deb）和修复依赖库查找路径的繁琐操作。ll-killer-go通过重建自由的容器环境，确保构建过程的一致性与可靠性，极大地提高了开发效率和可维护性。特色功能
apt install），但无需担心安全问题。build-aux中提供的一系列修复脚本能够自动处理图标/快捷方式和 相对目录符号链接OpenAtom-Linyaps/linyaps#1039 问题。ldd-check/ldd-search检查工具，可以自动扫描缺失的运行时库文件，并查找所在的包名并安装，确保应用能够正常运行。/dev设备文件，可以直接在容器环境中访问设备（该行为作为自由的容器环境的一部分体现，可以在entrypoint.sh中取消）。架构支持
ptrace功能支持。目录
ll-killerll-killer（可选）ifovl模式fuse-overlayfs模式merge模式（默认回退）命令概览
ll-killer-go提供了一些核心命令来帮助构建和管理玲珑容器应用：apt：进入隔离的 APT 环境。build：构建或进入构建环境。exec：进入运行时环境。run：启动容器，执行应用。commit：提交构建内容到玲珑容器。clean：清除构建内容。build-aux：创建辅助构建脚本。ptrace：修正系统调用（目前仅支持chown调用）。script：执行自定义构建流程。help：显示帮助信息。提示： ll-killer的每个子命令都内置了详尽的帮助信息，推荐查看。
快速打包教程
本章节将展示如何使用
ll-killer快速打包Ubuntu源中GIMP软件包，希望能够结合实际案例让大家更直观地了解ll-killer打包过程。整个过程无需配置库文件的环境变量，或对库文件进行修补，一切交给包管理器。[]~(￣▽￣)~*
** 提示：** 本教程默认使用merge模式进行根文件系统挂载，在文件冲突严重的情况下会显著增加启动时间，如需更佳的性能请在完成本教程后继续查看 高级进阶内容 章节。v1.2.0更新: 从v1.2.0版本开始，ll-killer默认启用fuse-overlayfs挂载模式，无需再提供外部二进制来启用。
1. 获取与配置
ll-killer首先，确保系统已安装必要的依赖：
然后，下载最新版本的
ll-killer并赋予执行权限（当前最新为v1.1.1）：以上脚本下载的是
amd64架构，ll-killer-go还支持arm64和loong64架构，可以修改链接中的amd64至其他版本，或进入项目Releases页手动下载。03-23日更新 镜像地址：为了解决国内用户的下载问题，维护了一个镜像地址，大家可以将上面命令中的GitHub链接替换为此地址进行下载
https://ll-killer.win/releases/latest/download/ll-killer-amd64
同时可以在此地址查看项目的release页，获取更新说明以及每个文件的哈希值等信息：
https://ll-killer.win/releases
其他下载方式
如果上面的链接下不动，可以网上搜索github release 下载加速，然后把链接粘进去加速下载，再把文件放入相应位置。
⚠警告：从第三方地址加速下载时，注意文件的安全性。Releases页面提供了各个文件的sha1校验码，在文件下载完成后务必使用
sha1sum校验文件的完整性。全局安装
ll-killer（可选）为了方便使用，可将
ll-killer安装到~/.local/bin：如果
~/.local/bin未添加至PATH，或提示找不到ll-killer命令，请执行：2. 开始打包 GIMP 示例应用
接下来的步骤默认
ll-killer已全局安装（加入PATH环境变量）。创建工作目录
此文件夹将作为玲珑工程文件夹。
配置软件源
创建
sources.list并填充 Ubuntu 24.04 noble 的软件源（也可以使用记事本创建此文件）：创建 linglong.yaml 项目文件
此步骤将
gimp包的元数据输出到pkg.info，再由ll-killer通过元数据创建项目，并指定包名为gimp.linyaps。进入构建环境并使用APT安装软件包
使用
ll-killer build命令进入Rootless构建环境（虚拟root身份），其中--ptrace参数可以解决Rootless安装deb包时出现的文件所有权问题。重要提示：
ll-killer build --ptrace -- bash可以进入交互式shell环境。ll-killer build命令反复进入构建环境，不会像ll-builder build那样每次运行都重置环境。ll-killer build命令默认启用--strict严格模式，确保构建环境与运行时环境完全一致，不会出现ll-builder build中引入构建依赖的问题。构建依赖属于幽灵依赖，会在运行时消失，因此有必要消除隐患。检查并修复幽灵依赖
此脚本执行以下步骤：
ldd-check.sh工具来检查环境中的缺失依赖，缺失文件名输出到ldd-check.log。ldd-search.sh工具查找ldd-check.log中列出的文件，并将找到的包写入ldd-found.log，仍然找不到的文件输出至ldd-notfound.log。导出layer文件
将文件导入
ll-builder的构建容器，同时使用--skip-output-check跳过ll-builder自带的ldd检查，使用--skip-strip-symbols跳过二进制的strip，最后导出layer文件。注意：玲珑版本>=v1.7.x才支持
--skip-output-check和--skip-strip-symbols参数，在此之前的版本无需传入此参数。此步骤完成后，最终会生成两个
.layer文件，仅需保留*_binary.layer。提示
ll-killer commit命令是ll-builder build的别名。ll-killer export命令是ll-builder export的别名。--双横线后传递ll-builder的参数。(v1.2.0之前)测试构建结果
此命令进入容器环境的shell，请结合desktop中的Exec指令来测试程序。
如需进入原始玲珑容器环境，请运行：
可以看到根目录下有
ll-killer和entrypoint.sh文件，同时bin目录下出现了gimp文件，我们运行gimp命令：可见正常运行，轻松秒杀。
提示
/opt/apps/APPID/files/entrypoint.sh入口点，因此ll-killer run/ll-builder run/ll-cli run不会启动具体的应用，具体的应用启动由desktop中的Exec指令指定。ll-killer run命令是ll-builder run的别名。--双横线后传递ll-builder的参数。(v1.2.0之前)安装构建结果
程序正常运行，但关于页面显示是2.10.36，不是检测到的2.10.38。这是由于我主机上也安装了gimp，deepin源中的GIMP版本为2.10.38，在创建项目时生成了本地安装的
2.10.38版本的pkg.info。但我们打包的是Ubuntu源中的GIMP，指定的是Ubuntu的源，里面的版本只更新到2.10.36，因此实际打包了2.10.36版本。此问题仅在主机上也安装了该应用时出现。ll-builder build环境已安装而跳过安装（如librsvg2-2），从而引起运行时的幽灵依赖，造成GIMP图标主题不能正常显示。[BUG] 桌面同名desktop文件与/var/lib/linglong/entries/share/applications的desktop冲突 · Issue #704 · OpenAtom-Linyaps/linyaps
命令汇总
以下脚本包含了本章节中的所有命令。
Makefile中，如果你希望使用make来管理构建流程，可以使用以下命令代替上面的全部：高级进阶内容
1. 定制根文件系统与挂载模式
你可以在
build-aux/entrypoint.sh中观察到如下代码，这些代码展示了ll-killer的默认根文件系统是如何构建的。--mount选项支持常见的挂载标志和文件系统类型，比如tmpfs/devpts/overlay等，并额外支持fuse-overlayfs和merge挂载模式。你可以在 System233/ll-killer-go#挂载相关功能 中找到详细的说明。
提示:
ll-killer exec本身作为一个简化版的容器，支持在没有玲珑的情况下独立运行，并创建独立的文件系统，它只是不使用基于文件的OCI配置以增强命令行的调用能力。2. 根文件系统挂载模式
ll-killer运行时默认使用fuse-overlayfs和merge两种挂载模式进行根文件系统的挂载。在未经额外配置的情况下，仅使用**merge**模式。具体的挂载规则请查看
build-aux/entrypoint.sh入口点文件。v1.2.0更新: 从v1.2.0版本开始，ll-killer默认启用fuse-overlayfs挂载模式，无需再提供外部二进制来启用。
ifovl模式 (internal-fuse-overlayfs) （自v1.2.0起）内置的
fuse-overlayfs命令，可取代外部fuse-overlayfs二进制。fuse-overlayfs模式fuse-overlayfs为 静态编译 或能直接在容器中运行。（v1.2.0前）fuse-overlayfs二进制文件复制到build-aux目录以启用。（v1.2.0前）ifovl模式实现，当指定外部二进制时，使用外部实现 （自v1.2.0起）fuse内核模块。merge模式（默认模式）fuse-overlayfs和fuse内核模块不可用或运行失败，则自动回退至merge模式。模式对比
fuseifovlfuse-overlayfsmerge3. 使用ll-killer辅助处理deb依赖但不安装
本案例的目的是方便传统手工打包者搜索和处理依赖，利用apt缓存功能自动下载某个包在base环境下所依赖的包。
由于操作在容器环境中进行，因此在多个打包操作同时进行的情况下，不会出现
ll-pica中的冲突情况。此外，由于使用的是base中的原生apt功能，搜索结果比ll-pica的aptly模糊匹配更加可靠，下载速度也更快。apt install的安装结果，只要它下载完成就行。4. 使用ll-killer辅助处理幽灵依赖
本案例展示如何单独使用
ll-killer的幽灵依赖检查功能，来帮助手工打包者查找deb包中未声明的依赖包名。前提条件
apt-file软件包。sources.list中指定的仓库具有Contents索引。结尾
更多信息和用法请查看命令帮助或项目主页：https://github.com/System233/ll-killer-go
更新日志
v1.4.x (2025-03-11)
代码调整
兼容性更改
新增功能
构建系统
错误修复
v1.3.0 (2025-03-10)
代码重构
兼容性更改
新增功能
错误修复
v1.2.x
run/export/commit三个ll-builder的别名命令将删除参数中的--分隔符，如果遇到不识别--的问题请删除此符号。v1.2.0
overlay子命令，实现了内置fuse-overlayfs支持，并添加了ifovl挂载类型选项。当指定fuse-overlayfs挂载时，若指定了fuse-overlayfs的二进制文件，则使用该文件，否则使用 内置的ifovl挂载。fuse-overlayfs挂载，无需再额外提供fuse-overlayfs二进制文件，merge挂载的性能问题得到彻底解决。systemd用户级服务单元支持，/etc/systemd下的所有服务单元将会被自动处理。不过目前玲珑1.7.x版本并不会自动启动服务，且容器内无法拉起服务，需等待玲珑后续版本改进情况；目前来看玲珑的systemd功能与应用卸载功能存在冲突。其他改动
commit/export别名命令无需再使用双横线。下一步计划
使用命名空间切换取代pty。（不可行）