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

Inizia leggendo DaemonAcquireProgress, in particolare la gestione menzionata di item.owner.error_text, e rivedi il commit di febbraio “Improve error handling” per il caso esistente di un errore di transazione vuoto. Confronta il modo in cui aptkit espone attualmente i fallimenti e definisci una direzione approvata dai maintainer per dettagli di fallback coerenti e rivolti all’utente; la discussione è conclusa quando vengono concordati l’ambito e l’approccio di presentazione.

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.