On Fri, Apr 21, 2017 at 12:09 PM, Guus Snijders <gsnijders@xxxxxxxxx> 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.
