Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

glut x86_64 build depends on incorrect version of array #43

Closed
LeifW opened this Issue · 12 comments

3 participants

@LeifW
Collaborator

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

@magthe
Owner

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

@peti

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

@magthe
Owner

Manually.

@peti

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.

@magthe
Owner

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.

@peti

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.

@magthe
Owner

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.

@peti

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?

@magthe
Owner

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.

@peti

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.

@magthe
Owner

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.

@peti

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
Something went wrong with that request. Please try again.