glut x86_64 build depends on incorrect version of array #43

Closed
LeifW opened this Issue Feb 18, 2011 · 12 comments

Comments

Projects
None yet
3 participants
Member

LeifW commented Feb 18, 2011

Depends on array-0.3.0.2, which has been removed from extra. GHC provides 0.3.0.1

Owner

magthe commented Feb 18, 2011

I've re-built it and uploaded a new version. That should fix it.

Contributor

peti commented Feb 21, 2011

I don't see any $pkgrel bump. How did you re-build that package?

Owner

magthe commented Feb 21, 2011

Manually.

Contributor

peti commented Feb 21, 2011

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.

Owner

magthe commented Feb 21, 2011

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.

Contributor

peti commented Feb 21, 2011

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.

Owner

magthe commented Feb 21, 2011

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.

Contributor

peti commented Feb 21, 2011

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?

Owner

magthe commented Feb 22, 2011

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.

Contributor

peti commented Feb 22, 2011

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.

Owner

magthe commented Feb 22, 2011

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.

Contributor

peti commented Feb 22, 2011

I don't know what you mean. Where did my commit message contain an "ad hominem" attack?

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment