hinata
deepin
2024-11-28 23:58
Reply Like 0 View the author
建议加精
所以玲珑runtime里面自带所有的dev包吗
反向打包还是挺容易的,可以搞一个专门的自动程序用shdeps去构建
感谢分享
Hello, the Deepin Spanish community is trying to learn how to use Linglong to package apps. We're also trying to understand how to use ll-pica to convert Debian packages to Linglong (Linyaps), but we're running into obstacles.
Does anyone have any free time to help us learn how to package Linglong (Linyaps) apps?
Popular Events
More
前言
有听过如意玲珑--新时代Linux桌面应用分发和治理方案的朋友应该知道如意玲珑方案众多核心特性之一就是: "通过隔离技术,彻底解决系统与应用、应用与应用之间因升级引起的兼容性冲突问题。"
基于此特性以及如意玲珑技术架构介绍, 我们可以大体知道如意玲珑方案主要通过沙箱、容器方案来对进行应用与系统间的隔离, 这意味着应用容器中的大部分目录仅具备只读权限, 无法当做日常系统环境来使用
恰逢在
2024年11月16日下午举办的如意玲珑开源社区首场高校技术沙龙中,如意玲珑与OpenTenBase开源社区开展了“跨界”分享, 在玲珑容器中试验性地进行了OpenTenBase开源项目的源代码编译. 而在活动结束后, 我继续针对如意玲珑与OpenTenBase开展跨界探索, 随之竟发现了可玩性(实用性)更高的场景玲珑容器操作展示
为了补偿部分朋友无法见证
如意玲珑与OpenTenBase开源社区“跨界”分享的现场演示, 我这里简单将操作过程向各位展示一遍前期准备
本次分享基于
deepin 23发行版, 因此在进行以下任意步骤前均需要准备一个可以构建玲珑应用的deepin 23系统环境具体步骤可参考:
linglong.yaml, 以此来生成一个符合要求的容器主要有以下需要关注的点:
* 由于本次操作是直接进入容器进行操作, 因此
build部分的构建规则可不详细写* 由于本次涉及编译操作, 为了能够极大程度包含所需的运行库, 我们加入
runtime段, 具体编写规范参考构建配置文件简介 玲珑应用构建工程基础知识具体步骤可参考:
linglong.yaml编辑并将相关源代码解压到当前目录下后, 我们就可以开始编译了项目编译演示
*这里需要插播一个知识点: 在玲珑容器中, 与构建工程配置文件
linglong.yaml同级的构建目录将被映射为/project目录万事俱备, 我们就可以开始编译了
玲珑容器操作和普通操作路径发生类似以下变化时, 即意味着我们已经进入玲珑容器中了
普通操作窗口解压openTenbase源码到构建目录中, 我这里单独解压到一个子目录中OpenTenBase开源项目已经为我们准备好了编译安装的入门文档, 我们可以先阅读 OpenTenBase源码编译安装 来准备编译材料apt联网安装依赖包的说法, 因此我们先跳过依赖安装步骤. 不过需要注意的是, 其中玲珑容器当前明确具备的库/编译器有:gcc12.3, zlib, openssl3, 其他暂未表明的库有可能不存在容器中而需要我们手动编译(记重点 , 后面要考)综上, 我们有可能会缺失文档中提示的
libreadline-dev libossp-uuid-dev玲珑容器操作窗口进入源码目录, 为了尽量避免对源目录的干扰, 我这里新建一个build目录用于编译. 进入build目录后我们输入OpenTenBase源码编译安装中的configure指令来配置构建工程. 根据玲珑应用构建工程基础知识, 我们将--prefix赋予$PREFIX的值, 最终我在本地执行了以下操作:libreadline库无法找到, 考虑到玲珑应用构建工程基础知识中提到的目录特性, 我单独检查了对应的include目录均无法找到与此库相关的资源结合此报错, 基本可以判断为该库缺失. 根据提示, 我们可以使用
--without-readline参数来禁用此库以跳过错误configure, 出现了uuid相关库丢失的情况, 由于不能完全确认库缺失情况, 我执行了./configure --help来查看当前工程支持哪些参数, 很快我就找到了和uuid的相关参数, 并更新成以下的参数:make操作即可bisonflex程序缺失的错误, 我们返回普通操作窗口将对应的源码下载到当前构建目录中, 进入玲珑容器操作窗口重新编译OpenTenBase项目, 和readline相关报错不存在了, 重新编译后, 第一次make可以成功完成了.make. 但出现了相对路径无法寻找的问题定睛一看, 这是因为我在编译上一级源码时使用了独立的编译目录, 破坏了原有的
Makefile设定, 因此我重新生成玲珑容器, 更换编译目录为configure同级目录, 按1==>11顺序完全编译一次即可但是这次
make中出现了readline头文件丢失的情况, 这意味着即便我们上一步禁用了此库, 想要完成所有二进制程序编译还是无法离开此库.我们参考
1==>10的步骤重新编译readline及其依赖运行库libncurses后, 也成功完成二次编译了编译结果测试
在完成
make install后, 由于--prefix被修改为了$PREFIX, 该变量也在容器默认PATH中, 因此我查看是否可以正常运行此二进制:至此, 足以证明
OpenTenBase项目可以在如意玲珑应用容器中成功编译并运行!二进制程序封装&二次分发
尽管如此, 我还是不满足. 我心里又萌生了一个玩法: 有没有方案可以将玲珑容器中编译的二进制文件导出, 并打包成
deb等传统包格式提供给暂不支持玲珑环境的发行版体验?很快, 我发现玲珑容器中是包含了
tar程序的, 结合/project路径可以映射为宿主机的构建目录, 我将$PREFIX目录封装为归档文件:返回
普通操作窗口, 发现我们通过宿主机也可以对此归档文件进行读写操作随后, 我将归档文件内的二进制文件封装为了deb安装包, 路径将
$PREFIX修改为传统的/usr其他基线相近的发行版安装使用由玲珑容器构建的二进制程序
在得到deb安装包后, 我在不同主流发行版上尝试体验, 来确认通过玲珑容器构建的二进制程序是否也存在通用性
deepin 23
openKylin 2.0
Ubuntu 2404
总结
显而易见, 不仅仅是通过玲珑容器封装的应用支持在不同发行版上使用(需要支持玲珑环境). 通过玲珑容器编译的二进制程序也支持在不同满足运行库要求的发行版上使用(暂不支持玲珑环境)