一、打包分享
前天看到吧里同仁推荐appimage,一时技痒,打算尝试。
经过两夜尝试,打包了一个tome4(马基埃亚尔的传说),分享一下吧。appimage原理就不说了,自行百度bin打包。现在单说打包。
官方github wiki文档分了几种情况,第一是从现有包(主要指deb、rpm这些)转化,这里面涉及到patch library问题,目的是解决依赖目录硬编译到字节码里的问题,让程序变成relocatable,也就是把应用变成绿色版。大部分是开源游戏,目前我没涉及这个,总的来说这个不是太难,稍微懂点shell的都能上手。
第二种是已经以绿色包发布的游戏,大部分是商业游戏,这个比较简单,但是目录看起来比较蛋疼。还有几种是专门针对特定情况的,比如mono等。
ps:官方制作了一些打包脚本,仅限有shell基础的朋友使用。
官方推荐的打包目录结构:
App.Dir/AppRun --这是一个运行脚本或二进制文件
App.Dir/.desktop文件 --桌面快捷方式文件
App.Dir/.png文件 --快捷方式会用到的logo图片
App.Dir/usr/bin --存放可执行程序的目录
App.Dir/usr/lib --存放依赖目录
但是在实际打包过程中,很难严格遵守这些依赖,看了官方的不少示例,也没有一个统一规范,实际上,只要你打开文件夹双击程序能执行,打成AppImage包就能运行。
拿我打包的tome4为例,我从官网下载的最新的1.4.9版,目录为:
tome4.Dir/AppRun
tome4.Dir/tome4.desktop
tome4.Dir/tome4.png
tome4.Dir/usr/bin
AppRun是一个脚本,内容为:
#!/bin/bash
if [ ! -d "$HOME/.t-engine" ]; then
mkdir -p $HOME/.t-engine/4.0/settings
echo "window.size = '1024x600 Windowscreen'" >> $HOME/.t-engine/4.0/settings/resolution.cfg
fi
HERE=$(cd "$(dirname "$0")"; pwd)
cd $HERE/usr/bin
./t-engine
if判断的原因是第一次运行tome4分辨率有问题,我hack了一下,第一次运行分辨率修改为窗口模式,1024*600分辨率。后面的才是重点,一定要获取绝对目录地址,然后执行应用,之前运行失败就是因为用的相对目录地址。
tome4.Dir/usr/bin里存放的就是tome4官网下载的tar.gz解压出来的文件。里面含有自带依赖,你看,没有遵守规范,依赖本来应该放在tome4.Dir/usr/lib,但是放不进去,依赖目录的文件夹名和位置都硬编码进去了,要么就path library,懒得写了(实际上是写了没起作用,原因不明),能跑就行。
二、评论
看了大量官方示例和实际操作后,我深深地感到AppImage的技术不成熟,原因有如下:
1、规范不明确,导致如果你撒手不管这个游戏,别人如果直接拿你的工程文件可能会一头雾水,不知道你怎么安排的目录,浪费了时间。如果我还写了很多行脚本,那对于不懂shell的人来说简直就没法入手。
2、技术不成熟,没有runtime,坐着等第三方提供,KDE已经提供了一套kde软件的打包runtime,那mono呢?javagame呢?pygame呢?没有现成的runtime意味着没有系统的依赖解决方案去兼容碎片化严重的linux发行版。应该自己编译一整套库,或者指明(或推荐)用哪个发行版编译和打包。
3、兼容性方案太差,AppImage解决依赖问题的方案我不喜欢,如果glibc不兼容,你就得自己手动打包一个旧的glibc版本进去,哪个库不兼容你就得手动打包一个旧的,可是如果新版本库不兼容debian旧版本库不兼容archlinux这怎么办?官方也没有讲这个怎么办,反正是测试三个发行版能跑就行(官方文档原话)。snappy这方面就很棒,你将软件所需要依赖(用ldd获取)写进配置脚本,会从软件仓库从glibc开始自动下载集成进去,兼容性绝对是杠杠的。appimage理论上也能做到,不过这样相当于每个开发者自己维护了一整套操作系统。
4、把所有文件拼接成一个文件,被打包的文件不用说也是只读了,你没法定制,比如我打包的这个tome4,如果你不喜欢我集成的汉化包,想自己换一个,不好意思,换不了,除非自己重打包。
5、吐槽归吐槽,appimage优点也很明显,达成一个包,而且可以直接运行,想法很好,windows也有这种做法,mac现在用的技术也类似这种。另外开发者很努力,相信一切问题随着时间都不再是问题。
最后为了保险,我把steam-runtime(ubuntu 12.04的依赖体系)集成了进去,结果就是增加了100多M的体积。
前天看到吧里同仁推荐appimage,一时技痒,打算尝试。
经过两夜尝试,打包了一个tome4(马基埃亚尔的传说),分享一下吧。appimage原理就不说了,自行百度bin打包。现在单说打包。
官方github wiki文档分了几种情况,第一是从现有包(主要指deb、rpm这些)转化,这里面涉及到patch library问题,目的是解决依赖目录硬编译到字节码里的问题,让程序变成relocatable,也就是把应用变成绿色版。大部分是开源游戏,目前我没涉及这个,总的来说这个不是太难,稍微懂点shell的都能上手。
第二种是已经以绿色包发布的游戏,大部分是商业游戏,这个比较简单,但是目录看起来比较蛋疼。还有几种是专门针对特定情况的,比如mono等。
ps:官方制作了一些打包脚本,仅限有shell基础的朋友使用。
官方推荐的打包目录结构:
App.Dir/AppRun --这是一个运行脚本或二进制文件
App.Dir/.desktop文件 --桌面快捷方式文件
App.Dir/.png文件 --快捷方式会用到的logo图片
App.Dir/usr/bin --存放可执行程序的目录
App.Dir/usr/lib --存放依赖目录
但是在实际打包过程中,很难严格遵守这些依赖,看了官方的不少示例,也没有一个统一规范,实际上,只要你打开文件夹双击程序能执行,打成AppImage包就能运行。
拿我打包的tome4为例,我从官网下载的最新的1.4.9版,目录为:
tome4.Dir/AppRun
tome4.Dir/tome4.desktop
tome4.Dir/tome4.png
tome4.Dir/usr/bin
AppRun是一个脚本,内容为:
#!/bin/bash
if [ ! -d "$HOME/.t-engine" ]; then
mkdir -p $HOME/.t-engine/4.0/settings
echo "window.size = '1024x600 Windowscreen'" >> $HOME/.t-engine/4.0/settings/resolution.cfg
fi
HERE=$(cd "$(dirname "$0")"; pwd)
cd $HERE/usr/bin
./t-engine
if判断的原因是第一次运行tome4分辨率有问题,我hack了一下,第一次运行分辨率修改为窗口模式,1024*600分辨率。后面的才是重点,一定要获取绝对目录地址,然后执行应用,之前运行失败就是因为用的相对目录地址。
tome4.Dir/usr/bin里存放的就是tome4官网下载的tar.gz解压出来的文件。里面含有自带依赖,你看,没有遵守规范,依赖本来应该放在tome4.Dir/usr/lib,但是放不进去,依赖目录的文件夹名和位置都硬编码进去了,要么就path library,懒得写了(实际上是写了没起作用,原因不明),能跑就行。
二、评论
看了大量官方示例和实际操作后,我深深地感到AppImage的技术不成熟,原因有如下:
1、规范不明确,导致如果你撒手不管这个游戏,别人如果直接拿你的工程文件可能会一头雾水,不知道你怎么安排的目录,浪费了时间。如果我还写了很多行脚本,那对于不懂shell的人来说简直就没法入手。
2、技术不成熟,没有runtime,坐着等第三方提供,KDE已经提供了一套kde软件的打包runtime,那mono呢?javagame呢?pygame呢?没有现成的runtime意味着没有系统的依赖解决方案去兼容碎片化严重的linux发行版。应该自己编译一整套库,或者指明(或推荐)用哪个发行版编译和打包。
3、兼容性方案太差,AppImage解决依赖问题的方案我不喜欢,如果glibc不兼容,你就得自己手动打包一个旧的glibc版本进去,哪个库不兼容你就得手动打包一个旧的,可是如果新版本库不兼容debian旧版本库不兼容archlinux这怎么办?官方也没有讲这个怎么办,反正是测试三个发行版能跑就行(官方文档原话)。snappy这方面就很棒,你将软件所需要依赖(用ldd获取)写进配置脚本,会从软件仓库从glibc开始自动下载集成进去,兼容性绝对是杠杠的。appimage理论上也能做到,不过这样相当于每个开发者自己维护了一整套操作系统。
4、把所有文件拼接成一个文件,被打包的文件不用说也是只读了,你没法定制,比如我打包的这个tome4,如果你不喜欢我集成的汉化包,想自己换一个,不好意思,换不了,除非自己重打包。
5、吐槽归吐槽,appimage优点也很明显,达成一个包,而且可以直接运行,想法很好,windows也有这种做法,mac现在用的技术也类似这种。另外开发者很努力,相信一切问题随着时间都不再是问题。
最后为了保险,我把steam-runtime(ubuntu 12.04的依赖体系)集成了进去,结果就是增加了100多M的体积。