Lui*_*uca 5 debian package-management
一些背景：我使用 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
没有任何好的结果。
我试图通过创建不同名称的包来寻找使用Provides或Enhances的方法
Package: local-libc6
Version: 2.15
# Either this:
Provides: libc6
# Or this:
Enhances: libc6 (< 2.15)
但到目前为止，我还没有成功equivs创建一个可安装的包（aptitude 抱怨提供或增强无效），甚至根本没有创建一个包。
当然，这个想法是创建一个虚拟包，libc它不会卸载已经安装的包，而只是“提供”新版本。但是到目前为止，我发现文档在这方面非常缺乏（而且我真的不想深入研究并迷失在 DPKG 百科全书中；通常我有能力和时间来完成这些任务，但是现在其他地方需要我的注意力）。
所以，我想基本问题是：我可以使用 equivs 在不卸载原始包的情况下为包创建更新，或者实现某种效果吗？在将版本指定为 时，我需要注意哪些一般问题equivs？
小智 2
答案是，使用equivs-build控制文件创建的包包含现有包和更高版本的名称（例如 libc6-local）的变体，将触发旧包的删除，而不是因为执行或来自新包或旧包的脚本，prerm而是postrm 设计使然。
现在，可以创建一个具有完全不同名称的包，并在它提供的控制文件中进行设置像 libc6 这样的包。更具体地说，请考虑针对建议的虚拟包的以下控制文件（仅显示相关部分）：
\n\nPackage: 6cbil-local //libc6 backwards is good enough\nVersion: 2.9\nProvides: glibc-2.9\nSection: libs\n将其与 libc6 2.17-0ubuntu5（我的机器）中的控制文件进行比较：
\n\nPackage: libc6\nSource: eglibc\nVersion: 2.17-0ubuntu5\nArchitecture: amd64\nMaintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>\nInstalled-Size: 10441\nDepends: debconf (>= 0.5) | debconf-2.0, libgcc1\nSuggests: glibc-doc, locales\nConflicts: prelink (<= 0.0.20090311-1), tzdata (<< 2007k-1), tzdata-etch\nBreaks: lsb-core (<= 3.2-27), nscd (<< 2.17)\nReplaces: libc6-amd64\nProvides: glibc-2.17-1\nSection: libs\nPriority: required\nMulti-Arch: same\n然后考虑基于此控制文件的空包：
\n\nPackage: using6\nVersion: 1.0\nDepends: libc6 (= 2.9) // it requires that specific version\n然后构建包。我们的虚拟包提供 glib-2.9安装并且不会删除任何已安装的 libc6。当您尝试安装依赖于 glibc-2.9 的软件包时，我们收到错误（此处apt设置为 2.2 ）：
The following packages have unmet dependencies:\n using6 : Depends: libc6 (= 2.9) but 2.17-0ubuntu5 is to be installed\nE: Unable to correct problems, you have held broken packages.\n或者dpkg：
dpkg: dependency problems prevent configuration of using6:\n using6 depends on libc6 (= 2.9); however:\n Version of libc6:amd64 on system is 2.17-0ubuntu5.\n返回到我们最初的虚拟包并将其提供的内容替换为：
\n\nProvides: glibc-2.9, libc6\n然后尝试重新安装我们依赖于 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:\n using6 : Depends: libc6 (= 2.9) //notice the reference to 2.17 is gone!!\nE: Unable to correct problems, you have held broken packages.\n这实际上与我在Debian 手册中错过的解释有点不同：
\n\n5.2.1.4.3。目前的限制
\n\n虚拟包受到一些令人不安的限制，其中最重要的是缺少版本号。返回到前面的示例，尽管存在 Perl 5.10，但包装系统 \xe2\x80\x94 永远不会认为依赖项如 Depends: libdigest-md5-perl (>= 1.6) 已满足，而事实上它很可能是满意的。软件包系统没有意识到这一点，会选择风险最小的选项，假设版本不匹配。
\n\n\n\n\n进一步发展 虚拟软件包版本 虽然现在虚拟软件包\n 不能有版本，但情况不一定总是如此。\n 事实上，apt 已经能够管理虚拟软件包的版本\n 并且很可能 dpkg最终也会的。然后，我们将能够编写诸如 Provides: libstorable-perl (= 1.7) 之类的字段来指示包提供与 1.7 版本中的 libstorable-perl 相同的功能。
\n
上面的经验表明，apt与dpkg我的设置（Xubuntu 13.04、dpkg=1.16.10 (amd64) 和 apt=0.9.7.7ubuntu4 (amd64)）的行为有些不同（就错误消息的变化而言）。Apt承认它看到我们安装的这个软件包提供了 libc6，但它没有看到它提供的正是版本 2.9。最终 apt 调用 dpkg 所以 dpkg 应该是瓶颈。
\n\n\n在我的设置中，在您的场景下，控制文件中\n“提供”的唯一值似乎是libc6。但是，由于当前的限制和设计，这还不足以允许安装依赖于特定版本的软件。
\n
最后，如您所知，ld.config.so是处理所有链接的工具，如ld.so.conf 文件和目录链的示例所示。共享对象的链接基础结构和 $LD_LIBRARY_PATH 变量优先于默认库位置，例如在此上下文中的 /lib 和 /usr/lib。
\n| 归档时间： |
|
| 查看次数： |
2290 次 |
| 最近记录： |