Discussion: a consistent way to show the real reason when an apt operation fails
还没有人认领这个 Issue。
评估
调研方向
先阅读 DaemonAcquireProgress，尤其是其中提到的 item.owner.error_text 处理，并查看 2 月份的“Improve error handling”提交，了解现有的空事务错误情况。比较 aptkit 当前如何暴露失败，并确定一项经维护者批准的方向，以提供一致的面向用户的 fallback 详细信息；当范围和呈现方式达成一致时，讨论即告完成。
由索引模型根据 Issue 内容生成。
描述
I'd like to open this as a discussion rather than a fixed feature request, since I think the right answer needs maintainer and user input before any code gets written.
Here's what set it off. An update failed for me in Update Manager. The dialog listed the files that failed to fetch but gave no reason behind them. I dug into it and the actual cause was a mirror that was mid-sync, so the package index and the real .deb files were briefly out of step. The thing is, a normal user has no way to ever reach that conclusion. They see "it failed" and that's the end of the road.
While reading the code I noticed aptkit already captures the per-item reason during download (item.owner.error_text in DaemonAcquireProgress). I also found the February "Improve error handling" commit that tackled this for the empty transaction-error case. So I know it's already on your radar, and that's part of why I think a wider conversation is worth having now.
What I'd really like to talk about is broader than this one dialog. When something in the apt stack fails, what should a non-technical person actually be shown? Right now it's uneven. Sometimes you get a useful apt message. Sometimes a generic "check your connection". Sometimes just a list of URLs with no reason attached. Someone who can't read /var/log/apt/term.log or rerun the command by hand gets nothing to start from.
A few things I'd genuinely like opinions on:
- Is there appetite for a consistent fallback, where whenever the high-level error is empty or generic, the captured per-item
error_textgets shown instead? - How much is too much? There's a tension between being helpful and dumping apt internals on someone who won't follow them. Maybe a short plain-language summary, with the raw detail behind an expander for those who want it?
- Should this kind of logic live in aptkit so every front-end benefits, or should each front-end decide how to present what aptkit hands it?
I'm not attached to any particular implementation. Mostly I want to know whether others hit this and what a good fix would look like to you. If there's already a direction you've settled on, I'd be glad to hear it. Thanks for all the work on this stack.
- 主要语言
- Python
- 星标
- 15
- 派生
- 10
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
linuxmint/aptkit 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 50/100
-
难度 3/5 1-2 天 新手友好度 48/100
-
难度 4/5 3-5 天 新手友好度 25/100
-
难度 3/5 1-2 天 新手友好度 35/100
-
难度 4/5 3-5 天 新手友好度 25/100
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复
-
area:docs
难度 2/5 1-3 小时 新手友好度 72/100
RailtownAI/railtracks#1633 ·
维护者通常 2 天内回复
-
review-panel severity:low
难度 1/5 1 小时以内 新手友好度 85/100
kristovatlas/coin-accounting#152 ·
维护者通常 1 天内回复
-
documentation :blue_book:
难度 1/5 1 小时以内 新手友好度 88/100
PennyLaneAI/pennylane#10280 ·
维护者通常 2 天内回复
-
`pipx reinstall` prints a Python traceback when the reinstall fails可能已有人在做 @ParamTanna 今天认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复