Recent change to Hackage causes delay in updates
I just found out the hard way that Hackage has been modified to allow minor edits of .cabal files without bumping the version number. This is not an uncontroversial feature[1]. The current situation is particularly irritating since the changes are reflected only on the web interface and the 00-index, but not in the packages themselves. The first victim of this is pandoc; the dependency on http-client in 1.13.1 has been changed. Previously it required a patch for ArchHaskell, but it doesn't any longer. Well, that is, it doesn't require one for creating the PKGBUILD (based on the 00-index), but it does while building (naturally based on the tar-ball). I'm currently thinking about possible solutions to this. Most likely I'll have to pull in the .cabal from the 00-index into the package and replace the one found in the tar-ball. However, I'd like to think about it a bit more before deciding how to handle it. So, the end result is that there won't be updates until I've had time to modify cblrepo to handle this :-( /M [1]: https://github.com/haskell/hackage-server/issues/52 -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay
What exactly is the unclear problem? Signalling the process of patching, or how the patching process works? -- SP
On Wed, Oct 29, 2014 at 10:13:51AM +0000, SP wrote:
What exactly is the unclear problem? Signalling the process of patching, or how the patching process works?
I'm not sure it's unclear. The problem is that the 00-index and the package now may contain different .cabal files for the same version of the package. This is a feature that apparently has been in the works for a while, but I wasn't aware of it until it bit me during an update yesterday (pandoc 1.13.1 is in this state on Hackage). Cblrepo is written with the assumption that the 00-index and the source tar-ball on Hackage *always* contain the same .cabal. So it clearly needs some work before it's back to being usable again. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Goto labels should be left-aligned in all caps and should include the programmer's name, home phone number, and credit card number. -- Abdul Nizar
On Wed, Oct 29, 2014 at 04:13:50PM +0100, Magnus Therning wrote:
On Wed, Oct 29, 2014 at 10:13:51AM +0000, SP wrote:
What exactly is the unclear problem? Signalling the process of patching, or how the patching process works?
I'm not sure it's unclear. The problem is that the 00-index and the package now may contain different .cabal files for the same version of the package. This is a feature that apparently has been in the works for a while, but I wasn't aware of it until it bit me during an update yesterday (pandoc 1.13.1 is in this state on Hackage).
Cblrepo is written with the assumption that the 00-index and the source tar-ball on Hackage *always* contain the same .cabal. So it clearly needs some work before it's back to being usable again.
Silly me! There's a rather obvious work-around that will allow me updating while working on a more convenient way to deal with this. Another update is building as I write this now :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus In a hierarchy, every employee tends to rise to his level of incompetence. -- The Peter Principle
On Wed, Nov 05, 2014 at 09:13:29AM +0000, SP wrote:
On 05/11/14 08:35, Magnus Therning wrote:
Silly me! There's a rather obvious work-around that will allow me updating while working on a more convenient way to deal with this.
How are you doing it in the end?
It's so embarrassingly simple... I extract the changes from the new .cabal into a patch on the source level. Specifically, I extract the changed .cabal for pandoc, which only existed in the index file, and put the changes into `patches/pandoc.source`, then I can remove `patches/pandoc.cabal`. It's not a very good long-term solution, but it makes it workable until I have finished refactoring `cblrepo` so it can deal with the situation more intelligently. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Any fool can write code that a computer can understand. Good programmers write code that humans can understand. -- Martin Fowler
On 06/11/14 08:55, Magnus Therning wrote:
Specifically, I extract the changed .cabal for pandoc, which only existed in the index file, and put the changes into `patches/pandoc.source`, then I can remove `patches/pandoc.cabal`.
Without experience in this, I was thinking that searching for diffs and automatic patching of the old cabals was one of doing it. But Apparently you don't care for the cabal? I mean it is only for deps anyway mostly right?
It's not a very good long-term solution, but it makes it workable until I have finished refactoring `cblrepo` so it can deal with the situation more intelligently.
What is coming up? -- SP
On Thu, Nov 06, 2014 at 09:55:30AM +0000, SP wrote:
On 06/11/14 08:55, Magnus Therning wrote:
Specifically, I extract the changed .cabal for pandoc, which only existed in the index file, and put the changes into `patches/pandoc.source`, then I can remove `patches/pandoc.cabal`.
Without experience in this, I was thinking that searching for diffs and automatic patching of the old cabals was one of doing it. But Apparently you don't care for the cabal? I mean it is only for deps anyway mostly right?
The .cabal is of course used to get to the dependencies, but beyond that it's not used for much in `cblrepo`, that's right. Automatic diffing would be one way. I was planning on simply copying in the correct .cabal (found in the index file) from the generated PKGBUILD. In either case the .cabal file has to be extracted from the index at `cblrepo pkgbuild`, something that hasn't been required earlier.
It's not a very good long-term solution, but it makes it workable until I have finished refactoring `cblrepo` so it can deal with the situation more intelligently.
What is coming up?
The plan is to do the following: - modify the database format to hold the x-revision - modify `cblrepo list` to show the x-revision - modify `cblrepo updates` to pull out the .cabal from the index when looking for updates (previously it was enough to just look at the path in the .cabal to determine if an updated package was available) - modify `cblrepo add` to deal with x-revision - modify `cblrepo pkgbuild` to extract the .cabal from the index and generate PKGBUILDs having it as a source and copying it into the build folder, the version number of the packages also should include the x-revision Before all of this I want to rewrite the handling (reading, patching, copying) of .cabal files slightly. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous
participants (2)
-
Magnus Therning -
SP