Msys2-packages: Package "coreutils" conflicts on update

[StarWolf3000]

Trying to install the recent update, pacman errors on coreutils, because libstdbuf.so (libstdbuf.so.exe) exists at /usr/lib/coreutils (file dated to Feb 14 2017), without forcing to override:
coreutils: /usr/lib/coreutils/libstdbuf.so existiert im Dateisystem
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.
translated:
coreutils: /usr/lib/coreutils/libstdbuf.so exists in filesystem
Errors occured, no packages were upgraded.

Updating from coreutils-8.26-1 to coreutils-8.26-2 (last change several hours ago, commit b35eb1c).

[lazka]

Hmm... this should have been prevented by the last pacman update. Maybe this got updated before pacman?

[StarWolf3000]

Pacman was up-to-date at this time and didn't show any available updates for itself. I enforced the update of coreutils with --force and it ran fine.
Strangely, on another Windows system, it worked out-of-the-box during the update, not giving any errors and the whole MSYS2 environment and installed packages were the same as on the system which gave that error.

[lazka]

Hm. Did you copy/rename libstdbuf.so.exe to libstdbuf.so to work around #541. That's the only thing I can think of. Otherwise no idea..

[StarWolf3000]

No, didn't do that.

But I think I know what went wrong: For some reason, pacman didn't show an upgrade for itself, because it identified the 5.0.1-4 as being older than 5.0.1.6403.520736d-1 (without checking the file dates of the packages).

I got behind this, when I checked out the file dates in the repository, which showed that my installed one was from March 2016, while the "downgrade" version was from 29 Sept 2017. Forcing it to "downgrade" to 5.0.1-4 (read: upgrade) with $ pacman -Syyuu installed that new one finally. Today I got again the "file exists" errors, this time on glib2 from Mingw-w64, but after the upgrade it went through.

Lesson learned: Never trust pacman's own versioning check. Closing this.

[lazka]

Uh, indeed.

$ vercmp.exe 5.0.1-4 5.0.1.6403.520736d-1
-1

Looks like the update on 15-Jul-2016 didn't increase the version number when changing the version scheme.

Thanks for figuring out what went wrong.