You can clone with
HTTPS or Subversion.
Depends on array-0.3.0.2, which has been removed from extra. GHC provides 0.3.0.1
I've re-built it and uploaded a new version. That should fix it.
I don't see any $pkgrel bump. How did you re-build that package?
Did the replace the file that was served on Andromeda with a re-built version?
Doing that wouldn't be a good idea, because users have already downloaded that tarball, and have it in their local /var/cache/pacman/pkg directory. If the file was changed afterwards, then they'll get "corrupt package" errors from Pacman because their locally cached version has a different hash than the one recorded in the database. Generally speaking, no file that was published on the server ought to be modified after the fact. Re-builds always require a bump of $pkgrel.
Yes, it was replaced by a re-built version, just like the broken one replaced a proper version.
User's can run pacman -Scc and pacman -Sy to fix up their local caches.
Unfortunately, pacman -Sy is not going to help, and pacman -Scc is going to prune the entire cache, which is not exactly a good solution.
Anyway, this is beside my point. Users can fix the breakage in many different ways. However, I feel strongly that a superior solution is not to break the repository in the first place. Instead of arguing that breaking the repository is not a big deal because users can work around that somehow, I'd rather argue that you shouldn't replace packages on the server that have already been published. Instead, please bump $pkgrel to trigger a rebuild so that our repository "just works".
Do you agree with that point of view?
And by the way, please don't close this issue until we've reached some kind of agreemenet. This is now the third time that I had to re-open it, and that feels kind of odd.
Sure, but in this case I didn't think it was worth it. The package in the repo went from working, to not working, back to working again, without any bumps of release version. The not-working build was only in the repo for a few days, and only one person reported it, so I made the judgement that it wasn't worth a bump.
Well, the situation we are in is that the x86_64 repository is potentially inconsistent from a user's perspective. The error messages pacman generates in such a case are not exactly unambiguous, meaning that we cannot expect all our users users to know how to remedy these errors. My impression is that we have two options how to proceed:
1) We bump the $pkgrel of all packages that might have been affected and rebuild them.
2) We post an article to the arch-haskelland haskell-cafe mailing list to explain the situation and to explain how users can fix those errors in case they occur.
Personally, I'm strongly in favor of (1).
What is your opinion in this matter? What would you suggest we do?
I suggest we do nothing.
We've had exactly one user who bumped into the initial problem, and not a single one reporting any issues since it was fixed.
Maybe we don't receive bug reports because people have given up using the x86_64 repository long ago because it's frequently broken?
Well, you go ahead and do nothing ... meanwhile I'll bump $pkgrel.
You may be right, but then you may just be overreacting as well.
I noticed you bumped the packages, I also noticed the ad hominem attack in the commit message. That is something I won't stand, those attacks you should keep to comments and emails. In response I removed your commit rights to habs.
I suggest we take the rest of this discussion in email.
I don't know what you mean. Where did my commit message contain an "ad hominem" attack?