一些背景：我使用 Debian 7 作为我的主要环境，我想告诉我的系统，除了使用一些更新的应用程序glibc = 2.15所需的环境之外，我还需要其他环境。glibc = 2.13
我从网上的各种安装教程中获取了 glibc，例如：Steam。它已解压/usr/local/lib/libc6-2.15，我已经使用一些应用程序（例如 Pidgin 2.10、Boinc 7 和 Stellarium）对其进行了测试，它运行良好（到目前为止，我做期望它最终会优雅地失败）。因为如果我也可以从打包源安装这些应用程序（例如 clang 和 Boinc 都在测试中），那就更好了，我想通过虚拟包告诉我的系统，事实上，我已经glibc 2.15 可用。
当然，我知道它equivs是一种为人们所做的事情创建虚拟包的工具不是已从存储库安装，但到目前为止，我还没有找到关于如何equivs创建虚拟包的良好文档，该虚拟包可以更新已安装的包，理想情况下不会破坏。
我首先尝试了显而易见的方法：
Package: libc6
Version: 2.15-1
并且 dpkg 安装了生成的软件包，预期结果是它卸载了已存在的libc更新并使系统处于不可用状态。 （当然，我在虚拟机中尝试过这个）。我也尝试过
Version: >= 2.13
没有任何好的结果。
我试图寻找一种使用方法提供或者增强通过创建不同名称的包
Package: local-libc6
Version: 2.15
# Either this:
Provides: libc6
# Or this:
Enhances: libc6 (< 2.15)
但到目前为止，我还没有成功创建equivs一个可安装的包（aptitude 抱怨提供或增强无效），甚至根本没有成功创建一个包。
当然，我们的想法是libc为此创建一个虚拟包惯于卸载已安装的版本，仅“提供”新版本。但到目前为止，我发现文档在这方面严重缺乏（而且我真的不想深入研究并迷失在 DPKG 百科全书中；通常我有能力和时间来完成此类任务，但这些天我的注意力需要放在其他地方）。
所以，我想基本问题是：能我使用 equivs 为软件包创建更新而不卸载原始软件包，或者实现某种效果？指定版本时需要注意哪些一般事项equivs？
答案1
答案是，equivs-build使用控制文件创建的包包含现有包和更高版本的名称（例如 libc6-local）的变体，将触发旧包的删除，而不是因为执行到prerm或postrm 脚本既不是来自新包，也不是来自旧包，而是来自设计。
现在，可以创建一个具有完全不同名称的包，并在控制文件中设置它提供像 libc6 这样的包。更具体地说，请考虑针对建议的虚拟包的以下控制文件（仅显示相关部分）：
Package: 6cbil-local //libc6 backwards is good enough
Version: 2.9
Provides: glibc-2.9
Section: libs
将其与 libc6 2.17-0ubuntu5（我的机器）中的控制文件进行比较：
Package: libc6
Source: eglibc
Version: 2.17-0ubuntu5
Architecture: amd64
Maintainer: Ubuntu Developers <[email protected]>
Installed-Size: 10441
Depends: debconf (>= 0.5) | debconf-2.0, libgcc1
Suggests: glibc-doc, locales
Conflicts: prelink (<= 0.0.20090311-1), tzdata (<< 2007k-1), tzdata-etch
Breaks: lsb-core (<= 3.2-27), nscd (<< 2.17)
Replaces: libc6-amd64
Provides: glibc-2.17-1
Section: libs
Priority: required
Multi-Arch: same
然后考虑基于此控制文件的空包：
Package: using6
Version: 1.0
Depends: libc6 (= 2.9) // it requires that specific version
然后构建包。我们的虚拟包提供了 glib-2.9安装并且不删除任何已安装的 libc6。当您尝试安装依赖于 glibc-2.9 的软件包时，我们会收到错误apt（设置为 2.2这里）：
The following packages have unmet dependencies:
using6 : Depends: libc6 (= 2.9) but 2.17-0ubuntu5 is to be installed
E: Unable to correct problems, you have held broken packages.
或者dpkg：
dpkg: dependency problems prevent configuration of using6:
using6 depends on libc6 (= 2.9); however:
Version of libc6:amd64 on system is 2.17-0ubuntu5.
返回到我们最初的虚拟包并将其提供的内容替换为：
Provides: glibc-2.9, libc6
然后尝试重新安装我们依赖于 glibc-2.9 的软件包。dpkg给出相同的错误消息，但不是apt！！！！实际上，当我在更改提供值后构建软件包时，Apt 就改变了主意，然后将更改推送到 Packages.gz 并用dpkg-scanpackages dirwithpackages | gzip > dirwithpackages/Packages.gzthen更新了 apt sudo apt-get update：
The following packages have unmet dependencies:
using6 : Depends: libc6 (= 2.9) //notice the reference to 2.17 is gone!!
E: Unable to correct problems, you have held broken packages.
这实际上与我在中错过的解释有点不同Debian 手册:
5.2.1.4.3。目前的限制
虚拟包受到一些令人不安的限制，其中最重要的是缺少版本号。返回到前面的示例，尽管存在 Perl 5.10，但诸如 Depends: libdigest-md5-perl (>= 1.6) 之类的依赖项永远不会被打包系统视为满足 — 而事实上它很可能已满足。软件包系统没有意识到这一点，会选择风险最小的选项，假设版本不匹配。
进一步发展 虚拟包版本 尽管现在虚拟包不能有版本，但情况不一定总是如此。事实上，apt 已经能够管理虚拟包的版本，并且 dpkg 最终也可能会这样做。然后，我们将能够编写诸如 Provides: libstorable-perl (= 1.7) 之类的字段来指示软件包提供与 1.7 版本中的 libstorable-perl 相同的功能。
上面的经验表明，与我的设置（Xubuntu 13.04、dpkg=1.16.10 (amd64) 和 apt=0.9.7.7ubuntu4 (amd64)）apt的dpkg行为有些不同（就错误消息的变化而言）。Apt承认它看到我们安装的这个软件包提供了 libc6，但它没有看到它提供的正是版本 2.9。最终 apt 调用 dpkg 所以 dpkg 应该是瓶颈。
在我的设置中，在您的场景下，对控制文件中的“提供”产生影响的唯一值似乎是库6。但由于当前的限制和设计，这还不足以允许安装依赖于特定版本的软件。
最后，如你所知，ld配置文件是处理所有链接的工具，如中所示这个例子ld.so.conf 文件和目录链的一部分。共享对象的链接基础结构和 $LD_LIBRARY_PATH 变量优先于默认库位置，例如在此上下文中的 /lib 和 /usr/lib。