| Summary: | History feature | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | Nate Graham <nate> |
| Component: | Updates | Assignee: | Aleix Pol <aleixpol> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | bugseforuns, elrefaei.omar, yvan |
| Priority: | NOR | ||
| Version First Reported In: | 5.13.3 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Nate Graham
2018-07-30 19:19:01 UTC
Maybe, I guess you're specifically talking about packagekit or any? Because the strategies that every system suggests to recover from an issue is different: snap it's channels, flatpak it's sources and internal versioning, distros it largely depends, on opensuse they have a cool stuff going on with btrfs. I'm afraid that the history would only be useful for reporting, but nothing one could do there. That's currently true, but un-actionable information can still be useful--not only for troubleshooting, but also just making the user feel more informed and in control. Also, an Update History page would support and be a prerequisite for the potential future features of error recovery and/or package/app version rollbacks. Muon has the history feature ad-hoc for apt. I'd say people can just use that if they need to interact with history. But I don't want to use Muon... If we are trying to streamline workflow: 1) Moun is a bit a more than the average user would be comfortable with. 2) This does not solve it for flatpaks & snaps <toMySelf> MAN THIS FRAGMENTATION IS FRUSTRATING </toMySelf> On a serious note: this is not the first time I see different packaging/distribution mechanism holding back feature development |