下一页 上一页 目录

4. 预编译二进制文件

4.1 rpm 有什么问题?

对于一些 Linux 用户来说,从源代码手动构建和安装软件包显然是一项令人畏惧的任务,以至于他们选择了流行的 rpmdeb 软件包格式,或者更新的 Stampede slp 软件包格式。 虽然 rpm 安装通常可能像在某个臭名昭著的操作系统中安装软件一样顺利和快速,但肯定应该考虑一下自安装预编译二进制文件的缺点。

首先,请注意,软件包通常首先以 “tarball” 形式发布,而预编译二进制文件会在几天、几周甚至几个月后才发布。 当前的 rpm 软件包通常至少比最新的 “tarball” 版本落后几个小版本。 因此,如果您希望跟上所有 “前沿” 软件,您可能不希望等待 rpmdeb 的出现。 一些不太流行的软件包可能永远不会被 rpm 化。

其次,“tarball” 软件包可能更完整,具有更多选项,并且更适合自定义和调整。 二进制 rpm 版本可能缺少完整版本的一些功能。 源代码 rpm 包含完整的源代码,相当于相应的 “tarball”,它们同样需要使用 rpm --recompile packagename.rpmrpm --rebuild packagename.rpm 选项来构建和安装。

第三,一些预编译二进制文件可能无法正确安装,即使安装成功,也可能会崩溃并生成核心转储文件。 它们可能依赖于与您的系统中存在的库版本不同的库版本,或者它们可能准备不当,或者只是完全损坏了。 无论如何,在安装 rpmdeb 时,您必然要信任打包它们的人的专业知识。

最后,手头有源代码有助于您能够修改和从中学习。 将源代码放在您从中构建二进制文件的归档文件中,而不是放在单独的源代码 rpm 中,要直接得多。

安装 rpm 软件包不一定是一件容易的事。 如果存在依赖冲突,rpm 安装将失败。 同样,如果 rpm 需要与您的系统中存在的库版本不同的库版本,即使您从现有库创建指向缺失库的符号链接,安装也可能无法工作。 尽管 rpm 安装很方便,但它们经常会因为与 “tarball” 安装相同的原因而失败。

您必须以 root 用户身份安装 rpmdeb,才能拥有必要的写入权限,这会打开一个潜在的严重安全漏洞,因为您可能会不小心覆盖系统二进制文件和库,甚至安装特洛伊木马,从而对您的系统造成严重破坏。 因此,从 “可信来源” 获取 rpmdeb 软件包非常重要。 无论如何,在安装之前,您应该对软件包运行 “签名检查”(针对 MD5 校验和),即 rpm --checksig packagename.rpm。 同样强烈建议运行 rpm -K --nopgp packagename.rpmdeb 软件包的相应命令是 dpkg -I | --info packagename.debdpkg -e | --control packagename.deb

对于真正偏执的用户(在这种情况下,偏执是有道理的),可以使用 unrpmrpmunpack 实用程序,这些实用程序可从 Sunsite utils/package directory 目录获得,用于解包和检查软件包的各个组件。

Klee Diene 编写了一个实验性的 dpkgcert 软件包,用于验证已安装的 .deb 文件针对 MD5 校验和的完整性。 它可从 Debian ftp 存档 获得。 当前软件包名称/版本是 dpkgcert_0.2-4.1_all.debJim Pick Software 站点维护一个实验性服务器数据库,为典型 Debian 安装中的软件包提供 dpkgcert 证书。

在最简单的形式中,命令 rpm -i packagename.rpmdpkg --install packagename.deb 会自动解包和安装软件。 但是,请谨慎操作,因为盲目使用这些命令可能会对您的系统健康造成危险!

请注意,上述警告也适用于 Slackware 的 pkgtool 安装实用程序,尽管程度较轻。 所有 “自动” 软件安装都需要谨慎。

martianalien 程序允许在 rpmdeb、Stampede slptar.gz 软件包格式之间进行转换。 这使得这些软件包可以用于所有 Linux 发行版。

仔细阅读 rpmdpkg 命令的手册页,并参考 RPM HOWTO、TFUG 的 Red Hat 软件包管理器快速指南 以及 Debian 软件包管理工具,以获取更详细的信息。

4.2 rpm 的问题:一个例子

Jan Hubicka 编写了一个非常好的分形软件包,名为 xaos。 在他的 主页 上,.tar.gzrpm 软件包都可用。 为了方便起见,让我们尝试 rpm 版本,而不是 “tarball” 版本。

不幸的是,xaos 的 rpm 安装失败。 两个不同的 rpm 版本都出现问题。

rpm -i --test XaoS-3.0-1.i386.rpm

error: failed dependencies:
        libslang.so.0 is needed by XaoS-3.0-1
        libpng.so.0 is needed by XaoS-3.0-1
        libaa.so.1 is needed by XaoS-3.0-1

rpm -i --test xaos-3.0-8.i386.rpm

error: failed dependencies:
        libaa.so.1 is needed by xaos-3.0-8

奇怪的是,在测试系统中,libslang.so.0libpng.so.0libaa.so.1 都存在于 /usr/lib 中。 xaos 的 rpm 肯定是用略微不同的库版本构建的,即使发布版本号相同。

作为测试,让我们尝试使用 --nodeps 选项安装 xaos-3.0-8.i386.rpm 以强制安装。 xaos 的试运行崩溃了。

xaos: error in loading shared libraries: xaos: undefined symbol: __fabsl

让我们执着地尝试找出问题的根源。 在 xaos 二进制文件上运行 ldd 以查找其库依赖项,显示所有必要的共享库都存在。 在 /usr/lib/libaa.so.1 库上运行 nm 以列出其符号引用,显示它确实缺少 __fabsl。 当然,缺少的引用可能也缺少在其他库中……除了替换一个或多个库之外,对此无能为力。

够了!下载 “tarball” XaoS-3.0.tar.gz,它可以从 ftp 站点 以及主页获得。 尝试构建它。 运行 ./configuremake,最后(以 root 用户身份)运行 make install,可以完美运行。

这是预编译二进制文件弊大于利的众多例子之一。


下一页 上一页 目录