DNF 走代理能通。GNOME Software 为什么不行？

GNOME Software 会把会话的代理设置交给 PackageKit；DNF 命令能成功，并不能证明图形界面下载使用了同一套配置。

DNF 下载软件包毫无怨言，GNOME Software 却能显示目录、一到安装就停住。人们很容易下结论说图形应用根本不理会代理。还有另一种可能：代理信息从未到达真正执行下载的那个组件。

顺着交接链路查

GNOME Software 和你在终端里敲的命令，配置路径并不相同。PackageKit 的代理文档描述了一个会话进程：它读取桌面设置，再转交给守护进程。在 GNOME 中，gnome-software 读取 GSettings，并调用 PackageKit 的代理设置接口。

随后守护进程把对应会话的设置交给自己的打包后端。也就是说，一次成功的 DNF 请求只能证明代理能为那次 DNF 调用服务，不能证明桌面会话把同样的设置注册给了 PackageKit。

三个有用的提问

  1. 哪个操作失败？ 查看目录数据、刷新元数据、下载软件包是三种不同操作，要记下真正报错的那一种。
  2. 会话代理是否注册成功？ 检查桌面的实际代理配置，以及 PackageKit 报告的错误。代理没设置成功，和下载时代理返回 407 是两回事。
  3. 这个设置属于哪个版本？ PackageKit 随时间变化。从 Fedora 25 时代回答里抄来的配置键，可能描述的是旧后端，或者早已不适用的缺陷。

终端里 export 的变量，不能可靠地代替这项交接检查。守护进程并不是你输入 export 的那个 shell 的子进程，图形登录的环境也可能不同。

修复要落在真正拥有问题的那一层。桌面配置错了，就改配置；注册失败，就保留错误和版本信息；代理拒绝了下载，就查它的认证或目标策略。把仓库文件一口气全改，只会模糊这些区别，让命令行和图形界面的配置都更难维护。

相关文章