Discussion: a consistent way to show the real reason when an apt operation fails

まず DaemonAcquireProgress を読み、特に言及されている item.owner.error_text の処理を確認し、既存の空のトランザクションエラーのケースについて、2月の「Improve error handling」コミットを確認します。aptkit が現在どのように失敗を公開しているかを比較し、一貫したユーザー向けのフォールバック詳細について、メンテナーが承認した方向性を定めます。その範囲と提示方法について合意できた時点で、議論は完了です。

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_text gets 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.