一、打包分享
前天看到吧里同仁推荐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的体积。
冰糖小树
Screenshot_20210218_1831121920×1080 442 KB
Screenshot_20210218_1831501920×1080 468 KB
