[arch-general] arch health

[Carsten Mattner]

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