自己写的，获取current需要更新的文件列表。

hj_18

然后我要列出自己的系统上现有的所有包列表，这个好办，ls /var/log/packages 即可。

hj_18

接下来，我要把服务器上的列表中的每一行分为两个部分，前者是软件包的名字，后者是版本号，对于自己已有的包列表也是这么划分，这样一来可以用循环来解决问题，把新表中的包名字放到旧表中去一行行的比对，如果对的上号的，说明找到了匹配的包，然后就比较它们的版本号，相同的话就不需要下载了，不同的话就加入到等待下载的列表。这样即使是新增加的包品种也不会漏掉。但怎样移出被抛弃的包？我得看看以前是不是打过这个功能的草稿，现阶段看起来还不要紧。

hj_18

感谢ginkgo提供的检查md5的好思路，不过这是建立在自己维护一个完整的安装目录树的基础上的。我也是有这样的想法，要把下载来的包维护到本地的树上，并且还写了把被更新的旧包自动删掉的脚本。md5sum的检查同样是消耗机器时间的大户，而我的脚本可以进一步优化到减少读文件的次数，并运用指针减少比对的次数，节省运行时间。
可是像rsync这样的软件我是信大不过的，因为我在家里开mldonkey，在单位要和一百多号菜鸟同事抢带宽，更别提他们机器上的arp病毒是怎么消耗带宽的。所以我有这样的经验，类似wget这样的单线程下载工具一旦被抢了带宽，往往陷入不可自拔的假死状态，这也是我写另一个脚本mydl.pl的不得已的苦衷，现在我有了等待下载的包列表，再用适合的下载工具，既省空间，又比较灵活。
哦，对了，我想起来了，我在写mydl.pl时发现wget的spider参数可以只读取文件名，不下载文件，可以用来建立文件列表，这样如果大家信不过FILE_LIST的话，就用这个办法建立源上的包列表的快照好了。

ginkgo

md5sum 每次只要跑一次就好，然后处理生成的tmp文件。
md5sum 全跑一次，最多两分钟，对于好几天才更新的话，开销不是很大。

根据这个可以很方便的，搞定下载文件列表。
下面的下载，用其他软件就好。不一定要只用wget。
FILE_LIST完全是可以信赖的。

slackcode

我还是喜欢rsync

grissiom

是不是 slackpkg 的 mirror 没有设置对？要不不会自动列出一堆12。2 的包来的～ 不过抢网速或许会是一个问题……

hj_18

怎样优化这个脚本呢，我原来是用嵌套循环的方法，
外面一层是每次读取新的列表文件中的一行，把它放进一个变量，我暂时称之为new-term；
里面一层是打开旧的列表文件，它的每一行就叫old-term。把new-term与old-term进行比较，再关闭文件。

这种算法效率低下，速度很慢。

现在我把新的列表文件按“/"进行分割域，按第二列来进行排序，这样就和旧的列表顺序一致了，然后我把旧表读入数组，反正文件不是很大。
现在我用一个变量作为数组的指针，当new-term和old-term比较后，如果对的上号，指针就增量了，这样下一个new-term 就从old-term上次比较的位置开始搜索，如果是新进入的包，却不增加指针的值。现在效率提高很大。

hj_18

当需要更新的包下载完毕后，怎么知道它是完整的呢，当然可以使用md5sum，但是我们是增量下载少数几个的包，没有必要把所有的包一起查一遍，从md5sum的文件中分离出需要check的行也很繁，所以我们可以导入slackware的公钥，利用asc文件来检验，这里有如何使用gnupg的介绍(http://waringid.blog.51cto.com/6 ... �，丰衣足食。
导入公钥用命令：
gpg --import 公钥文件
校验时用：
gpg --verify foo.asc foo

ginkgo

gpg 效验的效率，这个是每个文件一个效验文件，和用md5全部效验，效率差不多。

hj_18

比如说假如今天我有三个包要更新，一个在ap，一个在l，一个在xap。如果用md5sum校验的话，我要校验所有的包一遍。
但是用gpg校验asc文件的话，因为是一个包对应一个文件，所以只要校验三个包就可以了，哪个方法效率高是一目了然的事了。