搞Linux的老哥老姐们应该都有过这种经历刚接触Ubuntu那会儿装软件全靠网上搜教程人家说sudo apt install xxx就跟着敲装完也就装完了根本不知道系统里到底多了些什么。等到某天发现磁盘空间不够或者想确认某个包到底装没装、装的是哪个版本才开始意识到——包管理这件事不只是装得上还得查得清、管得住。这篇文章不打算讲那种apt命令大全式的罗列而是围绕两个最核心的问题展开Ubuntu上到底有哪几种安装包的途径以及怎么把已安装的包查得明明白白。我会把底层的逻辑、常用命令、以及我在实际运维中踩过的坑都翻出来讲适合刚入坑Linux的初学者也适合用了很久但一直没系统性梳理过包管理的老手。看完你至少能搞清楚apt和dpkg是什么关系、装包时背后发生了什么、查包时哪条命令最靠谱以及包出问题的时候怎么定位。1. Ubuntu包管理体系的底层逻辑apt和dpkg到底谁听谁的很多人用Ubuntu好几年apt install敲得飞起但问他apt和dpkg什么关系一脸懵。这事儿必须掰扯清楚因为后面所有安装、查询、排错的操作都建立在这两者关系之上。1.1 前端工具与后端引擎一个形象的类比你可以把dpkg想成是仓库里的叉车它负责最底层的装卸动作——把.deb这个货箱拆开、把文件放到指定位置、更新货物清单。而apt是仓库调度系统它不亲自搬货但它知道哪个货箱在哪个货架上软件源索引、这个货箱依赖哪些其他货箱依赖关系、是否有更新版本可以替换版本比较。换句话说dpkg -i xxx.deb直接安装一个本地deb包文件但不处理依赖。缺依赖就报错很死板。apt install xxx先从软件源索引里找到xxx分析依赖树把主包和所有依赖包一起下载然后逐个调用dpkg完成安装。这也是为什么你手动下载了个deb包双击安装有时会提示依赖不满足——因为你绕过了apt这个调度系统直接让叉车干活叉车不管别的货箱。1.2 软件源索引apt的消息来源apt之所以知道有哪些软件可用靠的是/etc/apt/sources.list和/etc/apt/sources.list.d/目录下的源文件。这些文件里写的是软件仓库的地址Ubuntu默认指向archive.ubuntu.com等官方源。你执行apt update的时候apt实际上是在拉取软件源的Packages索引文件这个索引文件里包含每个软件包的名字、版本、依赖关系、校验值等元数据apt把它们缓存到/var/lib/apt/lists/目录下。之后你执行apt install或者apt-cache search都是在这个本地缓存里检索不是每次实时访问网络。所以有个很常见的现象新装完系统后直接apt install某些包会提示找不到。不是软件不存在而是本地索引还没有得先apt update。这就是消息来源没更新的问题。1.3 dpkg的数据库包管理的账本dpkg维护着一个本地数据库核心文件是/var/lib/dpkg/status这个文件记录了系统里所有已安装包的状态是否已安装、版本号、依赖关系、安装时执行的脚本等。我们后面要讲的各种查询命令本质上都是去读这个账本。每个包安装后它的信息还会被拆分成多个文件放在/var/lib/dpkg/info/目录下比如包名.list记录了该包安装的所有文件路径包名.prerm和包名.postinst是卸载前和安装后要执行的脚本。理解了这个账本的存在你就能明白为什么有时候删一个包会留下配置文件为什么查询文件归属要用dpkg -S而不是apt——因为文件级别的信息只有dpkg记得最清。2. 装包的多种姿势不只有apt install一种路既然标题是安装/查看已安装包的方法安装这块得摊开讲。我按实际使用频率排个序从最常用到最不常用每种方法的适用场景和背后逻辑都说清楚。2.1 apt系列日常装机的主力军这是最标准的操作不啰嗦基本用法直接点几个容易被人忽略的细节sudo apt update # 更新索引装包前务必执行 sudo apt install 包名 # 安装 sudo apt install 包名版本号 # 安装指定版本 sudo apt install --no-install-recommends 包名 # 不装推荐的附带包--no-install-recommends这个参数值得多说一句。很多包在安装时会把Recommends级别的依赖也拉进来导致你只是想装个轻量工具结果多了一堆用不上的东西。比如装一些命令行工具时默认会把文档、额外插件都装上。如果你对系统整洁度有要求或者磁盘紧张这个参数能让装包更克制。但注意它只跳过推荐包不跳过Depends级别的硬依赖所以不会导致装完跑不起来。另一个细节是装包时sudo密码输完到真正下载之间会有一会儿停顿这是在读取软件源索引并解析依赖关系如果源文件很多、机器性能一般停顿几秒到十几秒都正常别以为卡死了。2.2 dpkg直接安装deb离线环境救星当你手里有一个.deb文件比如从官网下载的Google Chrome、TeamViewer、某些内网工具安装方式有两种sudo dpkg -i ./xxx.deb # 直接装但可能报依赖错误 sudo apt install ./xxx.deb # 推荐apt会读取本地deb并解决依赖很多人不知道apt其实是支持直接跟本地deb文件路径的。它的作用是apt会把这个deb的依赖关系纳入解析然后从软件源把缺的依赖一起装上。比dpkg -i后再手动apt install -f修依赖要省事得多。如果只能用dpkg -i装到一半报依赖关系未满足也别慌sudo apt install -f # 修复依赖自动把缺的依赖装上这个-f是--fix-broken专门用来处理处于半安装状态的包。2.3 源码编译安装最灵活也最费手源码装包的本质是用configure检测系统里的编译器和库文件生成Makefile然后make编译再make install把生成的文件拷到系统目录。整个过程绕过了dpkg的账本所以用源码安装的包dpkg是不知道的。./configure --prefix/usr/local make sudo make install这里有个关键的为什么--prefix参数决定了安装路径。默认很多软件会装到/usr/local下这样系统的/usr目录不会被污染卸载时把/usr/local/xxx整个目录删掉就行。如果你不指定--prefix有些软件默认装到/usr这会跟apt管理的文件混在一起日后想清理都不知道哪些文件是该软件的。源码安装最大的痛点是不参与依赖管理。你源码装了个软件它依赖的库版本和apt装的库冲突了apt完全不知道排查起来极其头疼。所以我的建议是能用apt或snap、flatpak解决的尽量别走源码安装必须源码装时优先checkinstall这类工具它能模拟出一个deb包来参与dpkg管理。2.4 snap和flatpak生态隔离的另一种思路Ubuntu从18.04开始默认预装snap很多新软件会优先推snap版本。它的特点是把软件本身和它依赖的库一起打包在一个沙箱环境里跟系统其他部分隔离。snap install 包名 snap list # 查看已安装的snap包 snap remove 包名flatpak在Ubuntu上不是预装的需要自己装但Fedora等发行版用得更多。两者思路类似都是应用商店化的尝试。这里要提醒一个问题snap装的软件和apt装的软件是两套体系查询时要用各自的命令。比如你apt list --installed里查不到snap装的软件得用snap list。很多人装了个软件找不到它在哪儿就是因为装完忘了自己用的是哪种方式。2.5 五种安装方式对比选型参考安装方式命令示例依赖处理卸载方式适用场景aptsudo apt install nginx自动解析依赖apt remove/purge日常安装首选dpkgsudo dpkg -i xxx.deb不处理依赖dpkg -r本地deb文件源码编译./configure make make install靠configure检测手动删除需要自定义编译参数snapsnap install xxx自带依赖隔离snap remove xxx新软件、沙箱隔离场景flatpakflatpak install xxx自带依赖隔离flatpak uninstall xxx跨发行版分发应用这份表格也是我日常排查的一个索引当系统里的包怪怪的第一件事是想清楚它是怎么装进来的再决定用哪套工具去管它。3. 查已安装包的实用命令从列表到文件归属一次讲透现在说查看这块。很多人只知其一——dpkg -l或者apt list --installed刷一屏列表就完事儿了。但实际工作中查包的需求是多种多样的有时候要知道某个包是否已安装有时候要知道某个命令是哪个包的有时候要知道已安装包里哪些不是系统自带的。各种需求对应不同的命令下面逐个展开。3.1 最基础的列出所有已安装包两条命令效果类似但细节有差异apt list --installed dpkg -lapt list --installed的输出格式是包名/发行版标识 版本号 架构 [状态]例如nginx/stable,now 1.24.0-1ubuntu1 amd64 [installed]最后那个[installed]表示已经安装如果是[installed,automatic]说明它是作为依赖被自动装上的不是用户主动装的。dpkg -l的输出格式是表格每行开头有两个字母ii正常安装状态第一个i表示期望安装第二个i表示实际已安装rc已卸载但配置文件还留着un未知状态没有安装iU期望安装但还没装上一般是安装中断了看包是否装好先看这两个字母是不是ii。这是我排查问题时的第一反应。一般查询时不会直接把几千行列表从头翻到尾而是配合grepdpkg -l | grep nginx apt list --installed | grep nginx3.2 精确判断某个具体包是否有安装如果只是想确认某个包是否存在、版本是多少更高效的方式dpkg -s 包名 # 显示包状态详情 apt-cache policy 包名 # 显示候选版本和当前已安装版本dpkg -s在包未安装时会输出一行dpkg-query: package xxx is not installed and no information is available然后退出码非0。可以用在脚本里做判断if dpkg -s nginx /dev/null 21; then echo nginx已安装 else echo nginx未安装 fiapt-cache policy更直观它会显示候选版本和已装版本常用于确认有没有更新的版本可以升级。3.3 反查文件归属这个文件是哪个包提供的这是被问得最多、也是很多人不知道的命令之一。当你拿到一个配置文件或者二进制文件想知道它从哪来dpkg -S /etc/nginx/nginx.conf # 输出nginx: /etc/nginx/nginx.conf反向查某一条命令属于哪个包dpkg -S $(which curl) # 输出curl: /usr/bin/curlwhich curl先找到curl命令的完整路径dpkg -S再反查这个路径属于哪个包。这个技巧在审计系统、排查可疑文件的时候特别有用。如果文件不是任何包提供的dpkg -S会提示path is not owned by any package大概率是源码编译生成的或者手动创建的。3.4 查询包安装了哪些文件跟上面的需求正好反过来已知某个包想知道它往系统里写了哪些文件。dpkg -L nginx输出是一串路径列表从/开始。比如nginx的输出会包含/etc/nginx/下的配置、/usr/sbin/nginx主程序、/lib/systemd/system/nginx.service服务文件等。这在卸载不干净需要手动清理时非常关键——先看看dpkg -L的输出就知道哪些残留文件是它的。3.5 区分手动安装和依赖自动安装apt-mark的妙用这个相对冷门但非常实用。你装软件A时apt自动把依赖B、C、D也装了。后来你想精简系统想知道哪些包是被连带着装上的可以查apt-mark showmanual # 显示所有手动安装的包 apt-mark showauto # 显示所有自动安装的包apt-mark showauto列出的包原则上都是被其他包带进来的。如果用不上apt autoremove会把它们清理掉。反过来如果你希望某个自动安装的包转正为手动包以免被反安装sudo apt-mark manual 包名当你想卸载一个包但不想让它自动把依赖一起卸掉时也可以先看看这个包是manual还是auto状态。在写自动化部署脚本的时候用apt-mark来筛选清理对象比手写一长串包名单要可靠得多。3.6 对比apt查询和dpkg查询什么时候用哪个查询需求推荐命令底层数据来源列出全部已装包apt list --installed/dpkg -ldpkg状态数据库查某个包是否安装及版本dpkg -s/apt-cache policydpkg状态数据库 / apt索引查命令/文件属于哪个包dpkg -Sdpkg文件清单查一个包安装了哪些文件dpkg -Ldpkg文件清单查手动/自动安装状态apt-mark showmanual/apt-mark showautoapt配置文件模糊搜索软件源里有没有某个包apt search 关键词apt本地索引 /var/lib/apt/lists核心区别一句话dpkg系命令读的是本地已安装数据库apt系命令还会读软件源索引。所以apt search能搜到还没装的包apt-cache policy能告诉你能否升级而dpkg -S和dpkg -L只关心已经装了的包。4. 安装和查询过程中踩过的坑完整的排查链路这一部分是我最想写的。命令本身不难难的是出了问题后你会不会慌。下面这几个场景全是我在实际操作中真实遇到的按现象 → 排查 → 解决的顺序完整还原。4.1 场景一安装时提示Unable to locate package这是新手最容易遇到、老手偶尔也会翻车的问题。明明软件名拼对了系统就是找不到。完整的排查链路应该是第一步确认拼写。大小写敏感nginx和Nginx是两个东西Linux世界里包名基本都是小写。第二步更新索引。新装的系统或刚改过源的机器本地索引很可能不存在该包信息sudo apt update第三步确认软件源里有没有。用apt search模糊搜索比如装不了mysql-server就搜apt search mysql如果搜索结果显示mysql-server存在说明只是索引旧了问题解决。第四步如果apt update时报错比如提示Failed to fetch或者Some index files failed to download通常是网络问题要么源连不上要么DNS解析有问题。这时候可以先试试换一个源。4.2 场景二dpkg安装中断导致的状态异常这个坑比较隐蔽我印象很深。有一次我装一个内网工具用dpkg -i装到一半网络挂了安装进程被中断。之后再想装任何包都报错E: dpkg was interrupted, you must manually run sudo dpkg --configure -a原因在于dpkg的账本里这个包的状态被标记为正在配置进程却没了。apt和dpkg发现账本处于中间状态就不敢继续操作了。处理方式sudo dpkg --configure -a这条命令会让dpkg重新执行所有处于等待配置状态的包的配置脚本。如果它还是卡住可以看看是哪个包出了问题考虑把它先移除sudo dpkg --remove --force-remove-reinstreq 包名这个--force-remove-reinstreq的意思是即使包处于需要重新安装的异常状态也强制移除。注意别乱用只在确认这个包已经放弃时才执行。4.3 场景三误删了/var/lib/apt/lists导致apt不可用有次清理磁盘空间我自作聪明把/var/lib/apt/lists目录直接删了心想这是缓存删了应该没事。结果再执行apt update直接报错apt完全不能用。原因/var/lib/apt/lists里的文件是软件源的索引缓存虽然理论上可以重新生成但apt在执行更新时对目录结构有要求目录没了它反而不知道从哪开始。解决sudo mkdir -p /var/lib/apt/lists/partial sudo apt updatepartial子目录是apt下载索引时的临时目录必须存在。补上之后再update就能正常拉取索引了。这事给我的教训是清缓存之前一定要搞清楚它是不是某个命令的工作目录不能光看缓存两个字就动手。4.4 场景四apt lock占用安装卡死装包时报这个错Could not get lock /var/lib/dpkg/lock-frontend说明有另一个apt/dpkg进程还在运行。最常见的原因是你开了两个终端一个还在执行apt操作另一个就开始装了。或者上次apt操作被强制关闭锁文件残留。排查ps aux | grep apt看看有没有apt进程在跑。如果有等它结束。如果没有说明是残留锁文件sudo rm /var/lib/dpkg/lock-frontend sudo rm /var/lib/dpkg/lock sudo rm /var/lib/apt/lists/lock但要强调直接删锁是下策。万一真有进程在写数据库你删了锁会让它写坏库。所以顺序一定是先确认没有apt进程再删锁。4.5 场景五查询时区分不了装没装和能不能用还有一个查询上的常见误判。dpkg -l | grep 包名显示包名存在就断定装好了但包可能是损坏状态。比如开机自启的服务起不来检查发现nginx包是iU或iF状态安装中断或半配置。这时候dpkg -s nginx会显示状态不是install ok installed。所以完整的确认一个包是否可用的判断逻辑是dpkg -l | grep 包名看首列是不是iidpkg -s 包名确认Status完整性如果服务类软件再验证systemctl status 服务名是否正常。三步缺一不可。只看第一步就断言装好了后面迟早出问题。4.6 场景六卸载后配置文件残留apt remove nginx之后再dpkg -l | grep nginx会看到状态变成了rc。这个r是removedc是config-files残留。说明程序本体删了但/etc/nginx下的配置文件还在。如果你想让系统彻底没有nginx的痕迹用purge而不是removesudo apt purge nginx或者对已经rc状态的包统一清理dpkg -l | grep ^rc | awk {print $2} | xargs sudo dpkg -P这条组合命令的意思列出所有rc状态的包取第二列的包名然后逐个彻底清除配置。我个人挺喜欢这条偶尔清理系统时会跑一下能腾出零星空间。5. 日常包管理习惯的养成一些花小钱办大事的技巧到这里安装和查询的方法基本讲完了。最后分享几个我在这几年操作中形成的习惯不一定写进文档里但确实能省不少事。5.1 装包后立即验证文件归属每次装完一个新包我会顺手记录三件事包名、版本号、主要可执行文件的路径。简单点就是跑一条组合命令dpkg -L 包名 | grep bin这样一旦日后需要排查某个命令被覆盖了文件找不到了之类的问题心里有个底稿。5.2 善用apt的history日志定位变更系统出了问题时想一想最近装了什么往往能快速缩小范围。Ubuntu的apt会记录安装历史日志文件在/var/log/apt/下ls /var/log/apt/里面有history.log和term.log前者记录安装了哪些包、版本、操作时间后者记录apt运行时的完整输出。history.log还有带gz扩展名的归档版本比如history.log.1.gz用zcat查看zcat /var/log/apt/history.log.1.gz | grep Commandline:这一招在复盘前几天还好好的今天突然不行了这种问题上特别好用。5.3 定期核对自动安装的包避免垃圾积累系统用久了自动安装的依赖包会越来越多。我一般每个月跑一次apt-mark showauto ~/auto_packages.txt然后过一遍这个文件看到明显没用的比如某个旧软件早已卸载但它的依赖还在就手动apt-mark manual确认或直接apt autoremove --dry-run看清理名单。autoremove --dry-run是试运行只列出会卸载的包不实际执行。先看名单再动手能避免误删。5.4 用别名把高频查询固化下来如果你和我一样每天要查大量包状态可以在~/.bashrc里加几条aliasalias pkgsapt list --installed alias pkgfdpkg -S alias pkgldpkg -L alias pkgcapt-cache policy alias fixdepsudo apt --fix-broken install alias fixcfgsudo dpkg --configure -a命名按自己习惯来目的是把需要记的命令缩短成好记的别名。我个人的体会是包管理命令本身不难记难的是在需要的时候能第一时间想到该用哪条。把这些命令固化成肌肉记忆比临时翻文档高效得多。5.5 最后一条算不上技巧的提醒在折腾服务器或者开发机时装包前先想清楚卸载路径。这一步很多人懒得起直接apt install等发现装错了、装多了清理的工作量反而更大。先apt-cache policy看一眼版本先apt-cache depends看一眼依赖花不了几秒钟但对系统洁净度的帮助非常明显。我从第一次在虚拟机里敲sudo apt install vim到现在踩过的坑不少但把apt和dpkg这套逻辑理解透彻之后遇到的绝大多数包管理问题都能用索引有没有更新、账本是否一致、是谁的依赖、状态是否完整四个问题来快速定位。希望这篇写下来的内容也能帮你把这套底层逻辑理顺。
Ubuntu软件包管理：apt与dpkg的关联及查询命令详解
搞Linux的老哥老姐们应该都有过这种经历刚接触Ubuntu那会儿装软件全靠网上搜教程人家说sudo apt install xxx就跟着敲装完也就装完了根本不知道系统里到底多了些什么。等到某天发现磁盘空间不够或者想确认某个包到底装没装、装的是哪个版本才开始意识到——包管理这件事不只是装得上还得查得清、管得住。这篇文章不打算讲那种apt命令大全式的罗列而是围绕两个最核心的问题展开Ubuntu上到底有哪几种安装包的途径以及怎么把已安装的包查得明明白白。我会把底层的逻辑、常用命令、以及我在实际运维中踩过的坑都翻出来讲适合刚入坑Linux的初学者也适合用了很久但一直没系统性梳理过包管理的老手。看完你至少能搞清楚apt和dpkg是什么关系、装包时背后发生了什么、查包时哪条命令最靠谱以及包出问题的时候怎么定位。1. Ubuntu包管理体系的底层逻辑apt和dpkg到底谁听谁的很多人用Ubuntu好几年apt install敲得飞起但问他apt和dpkg什么关系一脸懵。这事儿必须掰扯清楚因为后面所有安装、查询、排错的操作都建立在这两者关系之上。1.1 前端工具与后端引擎一个形象的类比你可以把dpkg想成是仓库里的叉车它负责最底层的装卸动作——把.deb这个货箱拆开、把文件放到指定位置、更新货物清单。而apt是仓库调度系统它不亲自搬货但它知道哪个货箱在哪个货架上软件源索引、这个货箱依赖哪些其他货箱依赖关系、是否有更新版本可以替换版本比较。换句话说dpkg -i xxx.deb直接安装一个本地deb包文件但不处理依赖。缺依赖就报错很死板。apt install xxx先从软件源索引里找到xxx分析依赖树把主包和所有依赖包一起下载然后逐个调用dpkg完成安装。这也是为什么你手动下载了个deb包双击安装有时会提示依赖不满足——因为你绕过了apt这个调度系统直接让叉车干活叉车不管别的货箱。1.2 软件源索引apt的消息来源apt之所以知道有哪些软件可用靠的是/etc/apt/sources.list和/etc/apt/sources.list.d/目录下的源文件。这些文件里写的是软件仓库的地址Ubuntu默认指向archive.ubuntu.com等官方源。你执行apt update的时候apt实际上是在拉取软件源的Packages索引文件这个索引文件里包含每个软件包的名字、版本、依赖关系、校验值等元数据apt把它们缓存到/var/lib/apt/lists/目录下。之后你执行apt install或者apt-cache search都是在这个本地缓存里检索不是每次实时访问网络。所以有个很常见的现象新装完系统后直接apt install某些包会提示找不到。不是软件不存在而是本地索引还没有得先apt update。这就是消息来源没更新的问题。1.3 dpkg的数据库包管理的账本dpkg维护着一个本地数据库核心文件是/var/lib/dpkg/status这个文件记录了系统里所有已安装包的状态是否已安装、版本号、依赖关系、安装时执行的脚本等。我们后面要讲的各种查询命令本质上都是去读这个账本。每个包安装后它的信息还会被拆分成多个文件放在/var/lib/dpkg/info/目录下比如包名.list记录了该包安装的所有文件路径包名.prerm和包名.postinst是卸载前和安装后要执行的脚本。理解了这个账本的存在你就能明白为什么有时候删一个包会留下配置文件为什么查询文件归属要用dpkg -S而不是apt——因为文件级别的信息只有dpkg记得最清。2. 装包的多种姿势不只有apt install一种路既然标题是安装/查看已安装包的方法安装这块得摊开讲。我按实际使用频率排个序从最常用到最不常用每种方法的适用场景和背后逻辑都说清楚。2.1 apt系列日常装机的主力军这是最标准的操作不啰嗦基本用法直接点几个容易被人忽略的细节sudo apt update # 更新索引装包前务必执行 sudo apt install 包名 # 安装 sudo apt install 包名版本号 # 安装指定版本 sudo apt install --no-install-recommends 包名 # 不装推荐的附带包--no-install-recommends这个参数值得多说一句。很多包在安装时会把Recommends级别的依赖也拉进来导致你只是想装个轻量工具结果多了一堆用不上的东西。比如装一些命令行工具时默认会把文档、额外插件都装上。如果你对系统整洁度有要求或者磁盘紧张这个参数能让装包更克制。但注意它只跳过推荐包不跳过Depends级别的硬依赖所以不会导致装完跑不起来。另一个细节是装包时sudo密码输完到真正下载之间会有一会儿停顿这是在读取软件源索引并解析依赖关系如果源文件很多、机器性能一般停顿几秒到十几秒都正常别以为卡死了。2.2 dpkg直接安装deb离线环境救星当你手里有一个.deb文件比如从官网下载的Google Chrome、TeamViewer、某些内网工具安装方式有两种sudo dpkg -i ./xxx.deb # 直接装但可能报依赖错误 sudo apt install ./xxx.deb # 推荐apt会读取本地deb并解决依赖很多人不知道apt其实是支持直接跟本地deb文件路径的。它的作用是apt会把这个deb的依赖关系纳入解析然后从软件源把缺的依赖一起装上。比dpkg -i后再手动apt install -f修依赖要省事得多。如果只能用dpkg -i装到一半报依赖关系未满足也别慌sudo apt install -f # 修复依赖自动把缺的依赖装上这个-f是--fix-broken专门用来处理处于半安装状态的包。2.3 源码编译安装最灵活也最费手源码装包的本质是用configure检测系统里的编译器和库文件生成Makefile然后make编译再make install把生成的文件拷到系统目录。整个过程绕过了dpkg的账本所以用源码安装的包dpkg是不知道的。./configure --prefix/usr/local make sudo make install这里有个关键的为什么--prefix参数决定了安装路径。默认很多软件会装到/usr/local下这样系统的/usr目录不会被污染卸载时把/usr/local/xxx整个目录删掉就行。如果你不指定--prefix有些软件默认装到/usr这会跟apt管理的文件混在一起日后想清理都不知道哪些文件是该软件的。源码安装最大的痛点是不参与依赖管理。你源码装了个软件它依赖的库版本和apt装的库冲突了apt完全不知道排查起来极其头疼。所以我的建议是能用apt或snap、flatpak解决的尽量别走源码安装必须源码装时优先checkinstall这类工具它能模拟出一个deb包来参与dpkg管理。2.4 snap和flatpak生态隔离的另一种思路Ubuntu从18.04开始默认预装snap很多新软件会优先推snap版本。它的特点是把软件本身和它依赖的库一起打包在一个沙箱环境里跟系统其他部分隔离。snap install 包名 snap list # 查看已安装的snap包 snap remove 包名flatpak在Ubuntu上不是预装的需要自己装但Fedora等发行版用得更多。两者思路类似都是应用商店化的尝试。这里要提醒一个问题snap装的软件和apt装的软件是两套体系查询时要用各自的命令。比如你apt list --installed里查不到snap装的软件得用snap list。很多人装了个软件找不到它在哪儿就是因为装完忘了自己用的是哪种方式。2.5 五种安装方式对比选型参考安装方式命令示例依赖处理卸载方式适用场景aptsudo apt install nginx自动解析依赖apt remove/purge日常安装首选dpkgsudo dpkg -i xxx.deb不处理依赖dpkg -r本地deb文件源码编译./configure make make install靠configure检测手动删除需要自定义编译参数snapsnap install xxx自带依赖隔离snap remove xxx新软件、沙箱隔离场景flatpakflatpak install xxx自带依赖隔离flatpak uninstall xxx跨发行版分发应用这份表格也是我日常排查的一个索引当系统里的包怪怪的第一件事是想清楚它是怎么装进来的再决定用哪套工具去管它。3. 查已安装包的实用命令从列表到文件归属一次讲透现在说查看这块。很多人只知其一——dpkg -l或者apt list --installed刷一屏列表就完事儿了。但实际工作中查包的需求是多种多样的有时候要知道某个包是否已安装有时候要知道某个命令是哪个包的有时候要知道已安装包里哪些不是系统自带的。各种需求对应不同的命令下面逐个展开。3.1 最基础的列出所有已安装包两条命令效果类似但细节有差异apt list --installed dpkg -lapt list --installed的输出格式是包名/发行版标识 版本号 架构 [状态]例如nginx/stable,now 1.24.0-1ubuntu1 amd64 [installed]最后那个[installed]表示已经安装如果是[installed,automatic]说明它是作为依赖被自动装上的不是用户主动装的。dpkg -l的输出格式是表格每行开头有两个字母ii正常安装状态第一个i表示期望安装第二个i表示实际已安装rc已卸载但配置文件还留着un未知状态没有安装iU期望安装但还没装上一般是安装中断了看包是否装好先看这两个字母是不是ii。这是我排查问题时的第一反应。一般查询时不会直接把几千行列表从头翻到尾而是配合grepdpkg -l | grep nginx apt list --installed | grep nginx3.2 精确判断某个具体包是否有安装如果只是想确认某个包是否存在、版本是多少更高效的方式dpkg -s 包名 # 显示包状态详情 apt-cache policy 包名 # 显示候选版本和当前已安装版本dpkg -s在包未安装时会输出一行dpkg-query: package xxx is not installed and no information is available然后退出码非0。可以用在脚本里做判断if dpkg -s nginx /dev/null 21; then echo nginx已安装 else echo nginx未安装 fiapt-cache policy更直观它会显示候选版本和已装版本常用于确认有没有更新的版本可以升级。3.3 反查文件归属这个文件是哪个包提供的这是被问得最多、也是很多人不知道的命令之一。当你拿到一个配置文件或者二进制文件想知道它从哪来dpkg -S /etc/nginx/nginx.conf # 输出nginx: /etc/nginx/nginx.conf反向查某一条命令属于哪个包dpkg -S $(which curl) # 输出curl: /usr/bin/curlwhich curl先找到curl命令的完整路径dpkg -S再反查这个路径属于哪个包。这个技巧在审计系统、排查可疑文件的时候特别有用。如果文件不是任何包提供的dpkg -S会提示path is not owned by any package大概率是源码编译生成的或者手动创建的。3.4 查询包安装了哪些文件跟上面的需求正好反过来已知某个包想知道它往系统里写了哪些文件。dpkg -L nginx输出是一串路径列表从/开始。比如nginx的输出会包含/etc/nginx/下的配置、/usr/sbin/nginx主程序、/lib/systemd/system/nginx.service服务文件等。这在卸载不干净需要手动清理时非常关键——先看看dpkg -L的输出就知道哪些残留文件是它的。3.5 区分手动安装和依赖自动安装apt-mark的妙用这个相对冷门但非常实用。你装软件A时apt自动把依赖B、C、D也装了。后来你想精简系统想知道哪些包是被连带着装上的可以查apt-mark showmanual # 显示所有手动安装的包 apt-mark showauto # 显示所有自动安装的包apt-mark showauto列出的包原则上都是被其他包带进来的。如果用不上apt autoremove会把它们清理掉。反过来如果你希望某个自动安装的包转正为手动包以免被反安装sudo apt-mark manual 包名当你想卸载一个包但不想让它自动把依赖一起卸掉时也可以先看看这个包是manual还是auto状态。在写自动化部署脚本的时候用apt-mark来筛选清理对象比手写一长串包名单要可靠得多。3.6 对比apt查询和dpkg查询什么时候用哪个查询需求推荐命令底层数据来源列出全部已装包apt list --installed/dpkg -ldpkg状态数据库查某个包是否安装及版本dpkg -s/apt-cache policydpkg状态数据库 / apt索引查命令/文件属于哪个包dpkg -Sdpkg文件清单查一个包安装了哪些文件dpkg -Ldpkg文件清单查手动/自动安装状态apt-mark showmanual/apt-mark showautoapt配置文件模糊搜索软件源里有没有某个包apt search 关键词apt本地索引 /var/lib/apt/lists核心区别一句话dpkg系命令读的是本地已安装数据库apt系命令还会读软件源索引。所以apt search能搜到还没装的包apt-cache policy能告诉你能否升级而dpkg -S和dpkg -L只关心已经装了的包。4. 安装和查询过程中踩过的坑完整的排查链路这一部分是我最想写的。命令本身不难难的是出了问题后你会不会慌。下面这几个场景全是我在实际操作中真实遇到的按现象 → 排查 → 解决的顺序完整还原。4.1 场景一安装时提示Unable to locate package这是新手最容易遇到、老手偶尔也会翻车的问题。明明软件名拼对了系统就是找不到。完整的排查链路应该是第一步确认拼写。大小写敏感nginx和Nginx是两个东西Linux世界里包名基本都是小写。第二步更新索引。新装的系统或刚改过源的机器本地索引很可能不存在该包信息sudo apt update第三步确认软件源里有没有。用apt search模糊搜索比如装不了mysql-server就搜apt search mysql如果搜索结果显示mysql-server存在说明只是索引旧了问题解决。第四步如果apt update时报错比如提示Failed to fetch或者Some index files failed to download通常是网络问题要么源连不上要么DNS解析有问题。这时候可以先试试换一个源。4.2 场景二dpkg安装中断导致的状态异常这个坑比较隐蔽我印象很深。有一次我装一个内网工具用dpkg -i装到一半网络挂了安装进程被中断。之后再想装任何包都报错E: dpkg was interrupted, you must manually run sudo dpkg --configure -a原因在于dpkg的账本里这个包的状态被标记为正在配置进程却没了。apt和dpkg发现账本处于中间状态就不敢继续操作了。处理方式sudo dpkg --configure -a这条命令会让dpkg重新执行所有处于等待配置状态的包的配置脚本。如果它还是卡住可以看看是哪个包出了问题考虑把它先移除sudo dpkg --remove --force-remove-reinstreq 包名这个--force-remove-reinstreq的意思是即使包处于需要重新安装的异常状态也强制移除。注意别乱用只在确认这个包已经放弃时才执行。4.3 场景三误删了/var/lib/apt/lists导致apt不可用有次清理磁盘空间我自作聪明把/var/lib/apt/lists目录直接删了心想这是缓存删了应该没事。结果再执行apt update直接报错apt完全不能用。原因/var/lib/apt/lists里的文件是软件源的索引缓存虽然理论上可以重新生成但apt在执行更新时对目录结构有要求目录没了它反而不知道从哪开始。解决sudo mkdir -p /var/lib/apt/lists/partial sudo apt updatepartial子目录是apt下载索引时的临时目录必须存在。补上之后再update就能正常拉取索引了。这事给我的教训是清缓存之前一定要搞清楚它是不是某个命令的工作目录不能光看缓存两个字就动手。4.4 场景四apt lock占用安装卡死装包时报这个错Could not get lock /var/lib/dpkg/lock-frontend说明有另一个apt/dpkg进程还在运行。最常见的原因是你开了两个终端一个还在执行apt操作另一个就开始装了。或者上次apt操作被强制关闭锁文件残留。排查ps aux | grep apt看看有没有apt进程在跑。如果有等它结束。如果没有说明是残留锁文件sudo rm /var/lib/dpkg/lock-frontend sudo rm /var/lib/dpkg/lock sudo rm /var/lib/apt/lists/lock但要强调直接删锁是下策。万一真有进程在写数据库你删了锁会让它写坏库。所以顺序一定是先确认没有apt进程再删锁。4.5 场景五查询时区分不了装没装和能不能用还有一个查询上的常见误判。dpkg -l | grep 包名显示包名存在就断定装好了但包可能是损坏状态。比如开机自启的服务起不来检查发现nginx包是iU或iF状态安装中断或半配置。这时候dpkg -s nginx会显示状态不是install ok installed。所以完整的确认一个包是否可用的判断逻辑是dpkg -l | grep 包名看首列是不是iidpkg -s 包名确认Status完整性如果服务类软件再验证systemctl status 服务名是否正常。三步缺一不可。只看第一步就断言装好了后面迟早出问题。4.6 场景六卸载后配置文件残留apt remove nginx之后再dpkg -l | grep nginx会看到状态变成了rc。这个r是removedc是config-files残留。说明程序本体删了但/etc/nginx下的配置文件还在。如果你想让系统彻底没有nginx的痕迹用purge而不是removesudo apt purge nginx或者对已经rc状态的包统一清理dpkg -l | grep ^rc | awk {print $2} | xargs sudo dpkg -P这条组合命令的意思列出所有rc状态的包取第二列的包名然后逐个彻底清除配置。我个人挺喜欢这条偶尔清理系统时会跑一下能腾出零星空间。5. 日常包管理习惯的养成一些花小钱办大事的技巧到这里安装和查询的方法基本讲完了。最后分享几个我在这几年操作中形成的习惯不一定写进文档里但确实能省不少事。5.1 装包后立即验证文件归属每次装完一个新包我会顺手记录三件事包名、版本号、主要可执行文件的路径。简单点就是跑一条组合命令dpkg -L 包名 | grep bin这样一旦日后需要排查某个命令被覆盖了文件找不到了之类的问题心里有个底稿。5.2 善用apt的history日志定位变更系统出了问题时想一想最近装了什么往往能快速缩小范围。Ubuntu的apt会记录安装历史日志文件在/var/log/apt/下ls /var/log/apt/里面有history.log和term.log前者记录安装了哪些包、版本、操作时间后者记录apt运行时的完整输出。history.log还有带gz扩展名的归档版本比如history.log.1.gz用zcat查看zcat /var/log/apt/history.log.1.gz | grep Commandline:这一招在复盘前几天还好好的今天突然不行了这种问题上特别好用。5.3 定期核对自动安装的包避免垃圾积累系统用久了自动安装的依赖包会越来越多。我一般每个月跑一次apt-mark showauto ~/auto_packages.txt然后过一遍这个文件看到明显没用的比如某个旧软件早已卸载但它的依赖还在就手动apt-mark manual确认或直接apt autoremove --dry-run看清理名单。autoremove --dry-run是试运行只列出会卸载的包不实际执行。先看名单再动手能避免误删。5.4 用别名把高频查询固化下来如果你和我一样每天要查大量包状态可以在~/.bashrc里加几条aliasalias pkgsapt list --installed alias pkgfdpkg -S alias pkgldpkg -L alias pkgcapt-cache policy alias fixdepsudo apt --fix-broken install alias fixcfgsudo dpkg --configure -a命名按自己习惯来目的是把需要记的命令缩短成好记的别名。我个人的体会是包管理命令本身不难记难的是在需要的时候能第一时间想到该用哪条。把这些命令固化成肌肉记忆比临时翻文档高效得多。5.5 最后一条算不上技巧的提醒在折腾服务器或者开发机时装包前先想清楚卸载路径。这一步很多人懒得起直接apt install等发现装错了、装多了清理的工作量反而更大。先apt-cache policy看一眼版本先apt-cache depends看一眼依赖花不了几秒钟但对系统洁净度的帮助非常明显。我从第一次在虚拟机里敲sudo apt install vim到现在踩过的坑不少但把apt和dpkg这套逻辑理解透彻之后遇到的绝大多数包管理问题都能用索引有没有更新、账本是否一致、是谁的依赖、状态是否完整四个问题来快速定位。希望这篇写下来的内容也能帮你把这套底层逻辑理顺。
