最近处理一台老服务器的软件包依赖问题时又碰到一条经典报错Depends: python2.7-minimal ( 2.7.15_rc1-1)但系统里已经装了另一个版本。这类问题在旧系统上非常常见尤其是仓库里还残留着 rc 版本包的时候。很多人的第一反应是用apt-get --force-yes强装或者直接dpkg --force-depends绕过检查结果包管理器状态越修越乱。这篇文章就把这类“版本锁死”问题的来龙去脉讲清楚重点说为什么推荐用aptitude来解决以及它和apt-get在依赖解析上到底差在哪里。适合正在维护老系统、经常被缺失依赖和版本冲突折磨的同学参考。1. 问题全景先搞懂这条依赖报错在说什么1.1 拆解报错信息Depends、精确版本与 rc 标记先看这条报错的完整形态。假设你执行了apt-get install some-package终端返回类似这样的内容The following packages have unmet dependencies: some-package : Depends: python2.7-minimal ( 2.7.15_rc1-1) but 2.7.15-1 is installed E: Unable to correct problems, you have held broken packages.这里面每个部分都有明确含义。Depends是 Debian 系包管理系统中最常见的一种依赖关系声明意思是“安装这个包之前另一个包必须已经存在”。括号里的是版本关系运算符代表“版本必须严格等于”。所以python2.7-minimal ( 2.7.15_rc1-1)的意思就是系统里当前时刻必须存在一个python2.7-minimal且版本号必须恰好是2.7.15_rc1-1。需要注意的是这里的版本号并不是普通的正式版本。rc1是 release candidate 的缩写表示公开测试版。旧仓库里出现的2.7.15_rc1-1说明这个包是从 Python 2.7.15 正式发布前的测试源打包并发布出去的。如果系统里已经装的是2.7.15-1或更高版本虽然看起来都是 2.7.15 一代但在包管理器眼里历史版本字符串不同就是“不满足依赖”。Debian 系版本比较有一套特殊规则不是简单按字典序比较。符号、数字、字母组合在一起会有先后的排序结果。比如~在比较规则里被当作“低于任何正常字符”处理这就是很多预发布版本被标记为比正式版本小的原因。而题目中_rc1这种写法属于某类仓库打包脚本留下的历史格式和常规的~rc1写法在排序上可能产生微妙的差异。换句话说你看到的“同一个大版本号”在包管理器的精确匹配规则下可能就是两个完全不同的版本。1.2 为什么 apt-get 经常解不开这种锁死问题要理解这个问题得先知道apt-get做依赖解析时有多“直线思维”。它的逻辑大致是这样的当你要安装包 AA 声明依赖 B 的某个精确版本系统里现有的 B 版本不满足条件于是 apt-get 到软件源里去找一个“恰好满足条件”的 B 版本。如果当前配置的源里没有这个版本它不会主动考虑“要不要把别的相关包先降级然后再装 B 的旧版本”更不会主动提出“移除另一个包来腾出版本空间”这种全局方案。它只会直接报错然后告诉你一句“held broken packages”。举例来说包 A 声明依赖python2.7-minimal ( 2.7.15_rc1-1)机器上装的是python2.7-minimal 2.7.15-1。你把源切回旧仓库让系统能重新看到2.7.15_rc1-1这个旧版本这时候如果用apt-get install python2.7-minimal2.7.15_rc1-1是可以把旧版本强行装回去的。但如果同时还有一堆别的包依赖当前的2.7.15-1那么 apt-get 在解决完一个依赖后下一个依赖又出现冲突很容易卡在一个循环里最后还是一样报错。它没有全局回溯能力遇到局部矛盾只能停止。这也解释了为什么网上很多解决方案会让人在 apt-get 后面加-f、--force-yes本质上是用“忽略依赖损坏风险”的方式去打破僵局。但这样做治标不治本哪怕当时成功了之后随便一次升级都可能再次触发同样的问题。1.3 典型触发场景与风险评估这类问题通常出现在几种典型场景中系统长期没做完整升级软件源里的包版本已经和本地已安装包产生了较大偏差。曾经手动下载过某个.deb包安装但那个包是按旧依赖关系打包的。某些第三方软件源被配置进系统第三方源里某个包的依赖锁定到了旧版本。之前一次dist-upgrade中断了导致 dpkg 数据库里的包版本信息和实际文件版本不一致。遇到这种报错最需要警惕的是在没有完全理解影响范围之前不要用破坏性的参数强装。apt-get --force-yes或dpkg --force-depends可能让包管理器数据库进入不一致状态之后你会面临“所有包都装不上、所有包都升级不了”的更棘手局面。正确做法是先备份包管理状态再选择合适的工具进行全局修复。2. 两条路线apt-get 与 aptitude 的依赖解析差异2.1 apt-get 的“贪心”策略局部最优都难保证apt-get的依赖解析器可以说是一种“贪心 线性”思路。它一次只处理一个未满足的依赖关系找到能解决当前问题的方案就采用找不到就报错。这种设计在大多数常规情况下是高效且稳定的因为普通用户安装软件时的依赖关系并不复杂绝大多数源里的包都能顺利找到满足条件的版本。但当环境出现“版本锁死”时贪心策略的弱点就暴露了。它不愿意推翻之前已经做过的选择也不愿意调整其他包的版本去迎合新需求。举个例子包 A 依赖 python2.7-minimal 2.7.15_rc1-1 包 B 依赖 python2.7-minimal 2.7.14 系统当前已装 2.7.15-1理想方案是“把 python2.7-minimal 降到 2.7.15_rc1-1同时检查 B 是否还能继续满足”。但 apt-get 相对较难自动生成这种“降级部分包”的完整方案它更习惯直接告诉你“找不到合适版本”。如果再加上包 A 和包 B 之间还存在其他相互依赖关系那么 apt-get 基本上只能原地转圈。2.2 aptitude 的“约束求解”思想全局回溯找可行解和 apt-get 相比aptitude的依赖解析器是另一个层级的东西。它把系统里所有包的状态看成一整套约束条件然后通过搜索算法去寻找一个“全局都说得通”的配置。这个概念很像解数独某一个格子填错了后面所有格子都算不对的时候回头看是哪个格子导致的然后把前面的选择修正再继续推导。实际使用中aptitude在冲突场景下会尝试多步回溯把可能的降级、升级、保留、移除方案都排查一遍。找到若干个候选方案后它会展示给用户选择。例如它可能会说方案一将python2.7-minimal降级到2.7.15_rc1-1同时将依赖它的另外两个包也一起降级。方案二保留当前版本但临时移除某个不再需要的包以满足某个依赖条件。方案三从其他源引入一个中间版本尽量少改动包列表。这就是为什么在依赖已经乱成一锅粥的机器上aptitude常常能给出 apt-get 给不出来的修复路径。它不只是找一个局部占位符而是为一整套包关系寻找可行解。2.3 对比表格什么时候用哪个更合适比较维度apt-getaptitude依赖解析策略线性、贪心、局部调整全局约束求解支持回溯冲突时是否提供多种方案基本不支持通常直接报错会列出多个候选方案让用户选择是否适合脚本自动化适合输出稳定、参数简单交互为主脚本化相对麻烦是否适合处理复杂依赖损坏较弱容易卡在 held broken 状态很强能找到降级 / 保留 / 移除组合方案学习成本低日常命令简单偏高交互界面与命令参数多一层日常装个常见包apt-get或apt完全够用跑脚本也干净利落。但当系统已经出现“无法纠正问题”的提示或者你明确知道存在多个包互锁时换aptitude去“理旧账”是更稳的路径。它有模拟模式可以在不改动系统的情况下先展示完整方案这是 apt-get 很难替代的优势。3. 实操用 aptitude 修复 python2.7-minimal 版本冲突的完整流程3.1 准备把 aptitude 装进一个依赖已经混乱的系统如果你现在的系统里还没有 aptitude第一步当然是安装它。但这里有个不太有趣的现实问题系统已经是依赖混乱状态apt-get install aptitude可能同样会因为依赖关系而失败。遇到这种情况可以换个方式cd /tmp apt-get download aptitude dpkg -i aptitude_*.debapt-get download的作用是只把安装包下载到当前目录不执行安装也不检查依赖。下载后直接dpkg -i强制安装通常 aptitude 自身的依赖比较轻量在大部分情况下可以装成功。如果dpkg -i提示缺几个运行库再用apt-get install -f自动补齐或者用apt-get download分别下载缺失的依赖包再手动安装。也可以先看一眼系统现在的包状态确认哪些包处于“半安装”状态dpkg -l | grep -E ^.[^i]如果输出里有大量iU或iF状态的包说明上次安装中断了先运行dpkg --configure -a把未配置完的包配置完再继续后面步骤。3.2 用模拟模式生成修复方案零风险的第一步aptitude 安装好之后不要急着直接改系统。先让它模拟一次安装操作看看它会建议怎么做。模拟模式不会修改任何包状态相当于干跑一遍。假设你要安装的包用target-package代替sudo aptitude -s install target-package这会在终端里打印出它“打算”执行的完整动作清单。重点看几个区域“将安装的 NEW 软件包”“将被降级的软件包”“将被保留的软件包”“将被移除的软件包”如果系统里确实存在python2.7-minimal的版本冲突你大概率会看到类似这样的描述下列软件包将被降级 python2.7-minimal [2.7.15-1 - 2.7.15_rc1-1]看到“降级”二字不要害怕。降级在依赖修复中是一种常规操作相当于把所有相关组件拉回到一个互相兼容的历史状态。关键是看降级清单里包括哪些包。如果仅仅是把python2.7-minimal和少数几个相关组件降级影响通常不大。如果同时要降级几十个系统库则要谨慎考虑是否符合预期。如果你想查看更多候选方案可以在 aptitude 的交互界面里按键e或E它会切换显示不同的解决方案。方案之间可能有细微差异有的偏保守、有的偏激进。我的建议是先选涉及软件包数量少的方案因为影响面越小后续出问题的概率越低。3.3 执行修复并验证系统状态确认方案没问题后去掉-s模拟参数直接执行sudo aptitude install target-package当 aptitude 展示最终修改计划时会要求你确认。此时可以按Y接受。如果看到某个你不想动的包出现在破坏性动作里按N拒绝然后重新按键查看其他方案。执行完以后把系统状态验证一遍是必须的不能看到安装成功就收工。依次跑这几条命令sudo dpkg --configure -a sudo apt-get check python2.7 --versiondpkg --configure -a用来处理所有可能残留的半配置状态apt-get check会检查当前整个系统的依赖关系是否有损坏最后确认 python2.7 版本确实变成了期望值。只要这三步都干净通过说明修复已经完成。3.4 备选方案手动指定版本、临时启用旧源与版本锁定aptitude 是首选方案但不是唯一方案。如果你的系统里 aptitude 也打不开局面还可以尝试这三条备用路线。第一条手动精确指定版本。如果软件源里仍然存在2.7.15_rc1-1这个版本可以直接用apt-get install python2.7-minimal2.7.15_rc1-1但前提是当前配置的源里有这个版本。先用apt-cache policy python2.7-minimal查看所有可用版本列表确认里面有2.7.15_rc1-1或相近版本的记录再执行安装。第二条临时启用旧版本软件源。如果当前源里已经没有旧版本了可以临时把一份旧源配置写入/etc/apt/sources.list.d/下的独立文件里。执行完安装后立刻把这个旧源文件移出去再运行apt-get update刷新。这样做的好处是避免旧源长期挂在系统里导致后续升级时所有包都被拽回旧版本。第三条用 apt-mark 锁定版本。如果你希望系统以后不再自动变更python2.7-minimal的版本可以执行apt-mark hold python2.7-minimal锁定后即使将来做dist-upgrade这个包也会被跳过。不过要明白hold是一种预防措施不是修复手段。它只适用于你已经确认某个版本必须保留的情况不能解决依赖冲突本身。4. 避坑实录我在实际排障中踩过的坑4.1 坑一aptitude 给出的方案也可能很“暴力”不要以为 aptitude 推荐的方案就一定是安全的。它是在全局搜索基础上找可行解但它没有能力判断某个包对你业务的重要性。比如有一次它给我的方案不仅降级了 python2.7-minimal还连带要把一个正在运行的数据库客户端库降级到旧版本理由是“为了满足另一个间接依赖关系”。如果当时我直接按Y业务服务可能当场报错。所以无论 aptitude 给出什么方案都要先看“将被移除”和“将被降级”这两个板块。凡是涉及正在运行的服务、数据库驱动、网络库的都要格外小心。必要时用aptitude -s多跑几个不同命令看看有没有影响面更小的替代路径。4.2 坑二修复失败后不要反复用 -f 硬闯依赖出错时网上常见的建议是apt-get -f install。这个命令本身没问题但它做的是“尽力修复”如果修复方案里涉及卸载某个包它也会毫不客气地执行。我遇到过有人连续执行多次apt-get -f install结果某个依赖包被卸载了业务直接不可用。如果-f修了几次还在报同样的错说明问题不是简单缺一个包而是存在深层版本冲突。这时候应该停止无意义的硬闯切到 aptitude 去生成全局方案或者先备份/var/lib/dpkg/status文件再做进一步操作sudo cp /var/lib/dpkg/status /var/lib/dpkg/status.bak这个备份文件在关键时刻能救你一命。万一操作坏了可以把备份覆盖回去恢复到之前的包状态。4.3 坑三aptitude 在大型软件源环境下运行较慢aptitude 的全局回溯算法虽然强但也因为算法复杂当系统配置了大量软件源、包数量上万时搜索方案需要花不少时间。看起来像是卡住了实际上它只是在遍历各种组合。此时不要急着按CtrlC多等一会儿。如果实在等不了可以用timeout 120 sudo aptitude -s install target-package给命令加一个超时时间超时后自动终止。但这只是减少等待痛苦的手段不代表问题一定能在 120 秒内解完。更稳妥的做法是在阶段性地等待时先通过aptitude search查看目标包的可用版本信息确认依赖关系大致方向后再执行安装。4.4 常见问题速查表报错或现象排查方向解决建议E: Unable to correct problems, you have held broken packages.是否有包被 hold或源里存在不兼容版本用apt-mark showhold查看锁定包用aptitude -s生成降级方案Version 2.7.15_rc1-1 not found当前源中没有旧版本记录临时使用包含旧包的源安装后移除旧源配置python2.7-minimal is already the newest version版本没变但仍提示依赖不满足细看apt-cache policy确认实际版本字符串复制完整版本号再执行精确安装aptitude提议移除大量依赖包全局方案影响面过大按N拒绝按e浏览其他方案优先选择改动量小的路径修复完成后其他服务异常降级了相关运行库检查降级清单必要时单独把受影响的服务所用库升级回原版本并重新评估依赖关系5. 长期维护建议避免下一次版本锁死5.1 依赖查询三板斧policy、madison、rdepends想彻底搞懂一个依赖问题的来龙去脉平时就要养成查包信息的习惯。最常用的三个命令是apt-cache policy python2.7-minimal apt-cache madison python2.7-minimal apt-rdepends -r python2.7-minimalpolicy会显示当前包的已安装版本、候选版本和每个源的可用版本能帮你快速判断“版本是不是断了”。madison更直接列出源里存在的所有版本号。apt-rdepends -r是反向依赖查询能列出“哪些包正在依赖这个包”这在评估降级影响时特别重要。比如你计划把python2.7-minimal降级但不知道会影响谁可以先apt-rdepends -r python2.7-minimal输出列表里每一个包都要纳入影响面评估。如果重要组件也依赖它降级前就要准备对应的备用方案。5.2 防患于未然hold、模拟升级和源管理很多依赖冲突不是突然出现的而是长期积累的结果。我在维护老服务器的过程里总结了几个实用习惯。第一对关键版本做hold处理。如果某个包必须固定在特定版本就用apt-mark hold锁死避免意外升级。第二执行大规模升级前先做一次模拟apt-get -s dist-upgrade模拟命令可以显示出所有将要升级、降级、删除的包帮你提前判断风险。第三第三方软件源不要长期挂在系统里。用完某个源之后及时注释或删除相关配置否则新旧源之间的版本差异会在某个时刻集中引爆。5.3 一点个人体会这次处理python2.7-minimal ( 2.7.15_rc1-1)问题我最大的感受是包管理器的选择本质上是在“局部调整”和“全局规划”之间做取舍。apt-get 追求简单直接aptitude 追求全局可行解没有谁绝对更好只有在不同场景下是否合适。遇到版本锁死时不要着急强装先认真跑一遍模拟把方案看明白再决定让系统往哪个方向走。这个习惯比记住任何一条具体命令都更值得培养。
