On Fri, Apr 21, 2017 at 12:09 PM, Guus Snijders email@example.com wrote:
If I may suggest a pain point: arch needs good support for revoking packages and replacing with the previous version if regressions are encountered.
From a user POV, that is something where Arch really stands out (for me, anyway). My procedure was always: #cleanup, keep current versions pacman -Sc #update all pkg's pacman -Syu
And when I run into a buggy package, install the previous version from the cached pkgs. That usually did the trick.
Yes it's easy to downgrade manually on a single machine, but my suggestion is about repo maintainers having a mechanism to force a downgrade via the index. This is less of an issue for LTS distros but important for non-testing users of Arch and other rolling distros. The package maintainer cannot know that 3.3 has a corruption bug and naturally trusts ffmpeg's announcement that 3.3 is a stable release. I did too and was surprised. It's my first ffmpeg surprise and usually ffmpeg is reliable.
I bring this up as a good precedent to consider such a mechanism since corruption is the worst kind of regression. A crash is easy to notice and work around but had I not watched the muxed videos myself, I wouldn't have seen the corruption until the number of videos would have been painfully large to queue for remux/re-coding.
In the past there have been just crashes or buggy behavior that only got fixed with the version-next++ and until then arch had to live with the broken and regressed version as the default since there wasn't a revoke/downgrade via the index. Since you can downgrade manually, the index ought to have mechanism for this too. Hope this makes sense.