问题描述参见此贴：http://tieba.baidu.com/p/3326880728
一时兴起，暂时设计了三套方案，会在下面逐个解释。
- 方案1 代号 go阿根廷-uploader1
- 方案2 代号 go阿根廷-uploader2
- 方案3 代号 go阿根廷-meta-package
- 方案4 代号 upload.sh
- 方案5 代号 go阿根廷-server
- 方案6 代号 go阿根廷-server2
问题描述
从 Go阿根廷 3.2.0 开始，服务端原来的 uploader.zip 被替换成了 uploader.py 和 google_appengine.zip 。由于 Google App Engine 的 SDK 是不允许分发的, 因此 [community] 仓库中的包 go阿根廷 在打包时必须去掉包含 Google App Engine 的 Python SDK 的文件 google_appengine.zip ，并且在 uploader.py 中去除有关 google_appengine.zip 的语句。
这样导致的结果是，单纯安装 [community] 仓库中的包 go阿根廷 3.2.0 版本，并执行以下命令上传服务端时会出现错误：
$ sudo python2 /usr/share/go阿根廷/server/uploader.py
Traceback (most recent call last):
File "/usr/share/go阿根廷/server/uploader.py", line 28, in <module>
import fancy_urllib
ImportError: No module named fancy_urllib出错原因是 fancy_urllib 在 google_appengine.zip 里面。
==========================
候选解决方案
先说说方案1，代号 go阿根廷-uploader1
这个方法是大神 @Felixonmars 提出的。
既然谷歌不准分发，只好删掉 google_appengine.zip，改为安装 AUR 上的 google-appengine-python 来替代了。又因为种种原因，在运行 python2 uploader.py 之前必须要设置 PYTHON_PATH 环境变量，让 python 知道 GAE 的 Python 库在哪里。而为了方便起见，就把它做成一个 bash 脚本，打进包里安装就行了。
所以这个方案就是在AUR上建立一个包 go阿根廷-uploader，用户与 go阿根廷 一起安装。
效果就是安装了这个包的同时会安装 google-appengine-python，安装完毕后只需要打开命令行执行
sudo go阿根廷-uploader就可以开始上传服务端了。
示例 PKGBUILD 参见：·https://gist.github.com/Firef0x/f682abaf49c045d4e4fc
==========================
然后是方案2，代号 go阿根廷-uploader2
方案1是使用了 AUR 上的包 google-appengine-python 来代替 google_appengine.zip ，但是我不确定 go阿根廷 会不会依赖特定版本的 GAE Python SDK ，以及这样做会不会有什么副作用。而且对于那些从不使用 GAE Python SDK 开发的人来说，相当于又多装了一个 AUR 软件包。既然都用 AUR 来绕过了，为什么不干脆把 go阿根廷 上游的 google_appengine.zip 直接打包呢？
所以这就是方案2，在AUR上建立一个包 go阿根廷-uploader，把 go阿根廷 删掉的文件重新打包，用户与 go阿根廷 一起安装。
但是由于 go阿根廷 同时也删掉了 uploader.py 的几行代码，这个包就必须同时打包原版的 uploader.py 文件，还不能覆盖掉 go阿根廷 的同名文件，所以只好折中地改一下名了（暂时改为 uploader1.py 吧）
效果就是安装了这个包后只需要打开命令行执行
sudo python2 /usr/share/go阿根廷/server/uploader1.py就可以开始上传服务端了。
示例 PKGBUILD 参见：https://gist.github.com/Firef0x/6a16c0ddf963ed05a612
==========================
最后是最激进的方案3，代号 go阿根廷-meta-package
早就觉得 go阿根廷 应该分为 本地端 和 服务端 两个包了，local 目录和 server 目录本来就是可以单独存在的，比如 smartladder(也就是 go阿根廷+) 就只保留了 local 目录，因为不是每个用户都需要自己上传服务端。而且服务端的代码更改的频率远远低于本地端的代码，从 go阿根廷 项目首页的版本历史里面的每个版本前面的 ”是“ 或者 ”否“ 就可以看出来。
把本地端和服务端分离，一是只有本地端更新的版本就无需再捆绑打包没有更新的服务端了；二是服务端单独更新以后，每次更新都相当于提醒用户需要重新上传服务端。
所以方案3就是把现在 [community] 仓库的 go阿根廷 包分割为 go阿根廷-client 和 go阿根廷-server，其中 go阿根廷-client 只打包 local 目录的文件，这部分文件是可以分发的；go阿根廷-server 只打包 server 目录的文件，这部分文件包含了不能分发的 google_appengine.zip。
于是，[community] 仓库的包 go阿根廷 就改名为 go阿根廷-client 了，并且在AUR上建立 go阿根廷-server。这样就保证了 go阿根廷 的原汁原味，不需要借助其他东西来保证功能正常。
当然，一般来说单独安装 go阿根廷-server 的情况不多，自己上传服务端的用户更多时候是同时安装 go阿根廷-client 和 go阿根廷-server 。所以就在 AUR 上建立一个空包 （也就是 Meta Package），命名为 go阿根廷，正好与旧的 go阿根廷想呼应。这个包依赖最新版本的 go阿根廷-client 和 go阿根廷-server，装上它后基本就和原来的 go阿根廷 包功能一样了。
示例 PKGBUILD 参见：https://gist.github.com/Firef0x/9af611c15f0efa36bbf0
=======================
方案4，代号 upload.sh 这个方案是由百度贴吧小吧主 四季飘尘提出的。
原文如下：
Win下安装 Go阿根廷 有个upload.bat 我想Lin下也可以与之对应upload.sh
通过运行upload.sh 给出Google_appen的公告 同时让用户了解到为何不能直接Upload 然后让用户选择是否继续上传 如果用户选择继续上传 则下载Google_appen至local文件夹 然后用sed加上PKGBUILD中改变的部分 然后继续运行upload.py。
以上是我的想法。
=======================
方案5，代号 go阿根廷-server 这个方案也是由大神 @Felixonmars 提出的。
原文如下：
（对于 go阿根廷-meta-package 方案，） 这里有个不好处理的问题: 有些用户并没有用集成 AUR 的自动更新工具, 拆开之后 go阿根廷 对于他们来说就是突然不升级了 (注意不能用 replaces, 否则 AUR 里的 meta 包就失去意义了)
相比之下, 我会建议 [community]/go阿根廷 不改名, 但是去掉 server 部分, 把整个 server 部分打包成 go阿根廷-server 放在 AUR 
=======================
方案6，代号 go阿根廷-server2 这个方案是由大神 @Lilydjwg 提出的。
原文如下：
我希望 local 一个包、server 一个包。server 包依赖 GAE SDK，并且带上传脚本。
go阿根廷 应该是不依赖 GAE SDK 的版本的，因为我一直是用 SDK 上传的（虽然已经很久没再上传过了）。
另外趁此机会整理一下 go阿根廷 包的内容，把 SwitchyOptions.bak SwitchySharp_1_9_52.crx 这些我从来用不到的东西拿出去，certs 目录之类的程序生成的东西放到 /var 下，然后给 go阿根廷 建立个专门的用户。
=======================
抛砖引玉，大家给点意见？？？
AD：同时混贴吧的可以到这里 http://tieba.baidu.com/p/3328497993 投票，本论坛的投票我不会搞……
:mad: